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ABSTRACT 


Level of Information System Interoperability (LISI) is a maturity model and 
interactive process for assessing and improving interoperability. The heart of the LISI 
concept is the formulation of a system ’’profile” which was created through the web- 
based LISI tool, Inspector 1.0. LISI considers five increasing levels of sophistication 
with respect to exchanging and sharing information and services. Each higher level 
represents a demonstrable increase in capabilities over the previous level of system-to- 
system interaction. The increase is expressed in terms of four attributes: Procedures, 
Applications, Infrastructure, and Data. LISI Inspector leverages the data captured in the 
Inspector Survey to generate four primary sets of assessment products to be as LISI 
management tool: Interoperability Profiles, Interoperability Assessment Matrices, 
Interoperability Comparison Tables, and Interoperability System Interface Description. 
A principal finding of this research is that LISI has potential to improve DOD C4I 
systems’ interoperability but the current LISI tool has to be refined. Also, LISI must 
continue to evolve and adopt the dynamic nature of military operations, system 
acquisition, and technology improvements so LISI can be useful in contributing to the 
improvement of DOD C4I systems’ interoperability and to achieve the Information 
Superiority envisioned by Joint Vision 2010. 
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I. INTRODUCTION 


A. PURPOSE 

The purpose of this research paper is to investigate whether Levels of Information 
Systems Interoperability (LISI), a computer software process, can improve Department of 
Defense (DOD) Command, Control, Communications, Computers, and Intelligence (C4I) 
systems’ interoperability. This is accomplished by researching the development of LISI 
and analyzing why LISI was implemented, what the elements of LISI capabilities model 
are, how the LISI process works, and whether it can actually improve the interoperability. 

B. BACKGROUND 

Command, Control, Communications, Computers, and Intelligence (C4I) systems 
relay critical information to U.S. forces during joint operations. If joint operations are to 
be successful, C4I systems must be ’’interoperable,” i.e., capable of exchanging 
information and operating effectively together. However, the military services have a 
long history of interoperability problems during joint operations. For example, the 
success of the Persian Gulf War in 1991, a major joint military operation, was hampered 
by a lack of basic interoperability. Since then, the DOD has had a number of initiatives 
to address various aspects of interoperability including Joint Tactical Architecture, 
Defense Information Infrastructure/Common Operating Environment (DII/COE), DII 
Master Plan, Shared Data Environment (SHADE), Joint Battle Center (JBC), Joint 
Interoperability Test Command (JITC). 

Commencing in 1993, EISI has continued to advance in capability through several 
phases. The “Exploratory Phase” in 1994 consisted of an initial assessment for Joint 
Task Eorce Operations in support of the Intelligence Systems Council (ISC). During the 
“Analysis Phase” in 1996, the EISI Maturity Model and assessment process was 
developed. The “Proof of Concept Phase” in 1997 began to implement the process with 
an automated prototype and examined the EISI capability through a set of preliminary 
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tests. During the FY99 “Development Phase,” six organizations to include the U. S. 
Army Program Executive Office, Command, Control, and Communications (PEO CSS) 
examined and tested the prototype for its utility in assessing and potential for identifying 
ways of improving interoperability. The 1999 “Development Phase” was accelerated as 
the result of the U. S. General Accounting Office (GAO) audit report: Joint Military 
Operations: Weaknesses in DOD’s Process for Certifying C4I systems’ Interoperability. 

My personal interest in the area of information system interoperability started in 
August 1997 when I joined PEO CSS. As a member of the 1997 inaugural Competitive 
Development Group (CDG), I was assigned in PEO CSS to commence my three years of 
cross-functional and leadership training. The fifty-plus mission critical CSS systems 
under that PEO overwhelmed me after my previous 10 years of program management 
experience mainly in business and financial management. I often wondered how these 
systems interoperate and fit into the Army Battle Command Systems (ABCS) to support 
DOD’s Eirst Digital Division (EDD). Even without strong background in the area of 
information systems, I put down “Interoperability” as my planned thesis consideration on 
my Naval Postgraduate School application form without any hesitation. 

Working in the Horizontal Technology Integration Office (HTIO), PEO CSS, I 
was privileged to have firsthand information on EISI progress and to have Mr. Tony 
Kunsaitis as my associate thesis advisor. Tony is the Interoperability Manager for PEO 
CSS, and this PEO was the first in the Army to be involved in the EISI efforts. Although 
EISI was initiated in I99S, it is still foreign for the majority of the program management 
community. My original discussion with Mr. Kunsaitis about this thesis was to 
concentrate on how useful EISI would be to the Program Managers, and I hoped to 
convince the Program Managers to choose EISI as their interoperability tool. However, a 
memo signed by both ETG Peter M. Cuviello and ETG Paul J. Kem to mandate the use 
of EISI changed my thesis concentration. Since the Program Managers do not have a 
choice but to use EISI, I believe that it would be more beneficial to research whether 
using EISI can actually improve the interoperability, and if any improvements of EISI 
can be made. Therefore, the purpose of this study is to examine whether EISI can 
improve information systems’ interoperability. 
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C. RESEARCH QUESTIONS 


1. Prime Research Question 

Can Levels of Information System Interoperability (LISI), a computer software 
applications and database with associated processes, improve DOD C4I systems’ 
interoperability ? 

2. Subsidiary Research Questions 

1. What is LISI? 

2. What are central elements of LISI and associated process? 

3. What are the motivations to implement LISI? 

4. How does LISI process work? 

5. Is the LISI system secured? 

6. Is the LISI system user-friendly? 

7. Can LISI improve DOD C4I systems’ interoperability? 

D. SCOPE 

There are five factors that have shaped the scope of my thesis. First, I am 
personally interested in information system interoperability. Second, there are GAO- 
reported weaknesses in DOD’s process for certifying C4I systems’ interoperability. 
Third, MITRE claims that LISI is the only DOD interoperability improvement initiative 
that can fill in the gaps between all the other initiatives, whether taken individually or 
collectively. Fourth, a pilot assessment of the LISI has been completed, using 
components of the Army Battle Command System (ABCS). Last but not least, the use of 
LISI has become mandatory. Therefore, the scope of the thesis is framed in how LISI can 
be used and how it can be improved, not whether LISI should be used. 
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E. METHODOLOGY 


After deciding that I would write about information system interoperability, and 
hearing that LISI could be the solution for interoperability impro’vement, I started asking 
Mr. Kunsaitis a lot of questions about interoperability and the details of the LISI 
progress. I browsed through the LISI report of October 1999 after MITRE completed its 
pilot assessment of the LISI using data on components of the ABCS. I gained the overall 
knowledge on what LISI actually is about and what its process and execution involve. I 
had my thesis originally planned to show how the LISI can help the PMs and hopefully to 
convince them to use the LISI. When the use of LISI became mandatory, the need to 
convince the PMs to utilize LISI remains, but I believe that it is more prudent to research 
if LISI can actually improve interoperability, if any modification of LISI can further 
improve the interoperability, and not whether USI should be used. 

The MITRE Corporation has been the EISI developer for the Army since 1993. 

To further support the Army System Engineering Office (ASEO) and Horizontal 
Technology Integration (HTIO), PEO CSS, MITRE delivered and configured a Prototype 
server at HTIO, PEO CSS. MITRE conducted a pilot EISI assessment of a selected 
subset of ABCS components in 1999. In early coordination discussions MITRE 
concluded that three systems about the complexity of the All Source Analysis System 
(ASAS) would be a workable analysis for the effort to recommend changes to the data 
collection capability of EISI. Eollowing that, the assessment of a full set of 10 to 11 
ABCS component systems was completed. The EISI data collection (survey) portion of 
the prototype was developed to collect information about a system through the use of a 
common web-based browser as the interface. Once the information is entered, the 
prototype applies the four levels, four parameter EISI paradigm to produce the 
interoperability profile of a system. This yields a quantitative measure of a system’s (or 
interfaces’) interoperability potential. The result of this pilot assessment of the EISI was 
reported in October 1999 by MITRE. 
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F. ORGANIZATION OF THE STUDY 


Chapter II provides an overview of LISI, its elements, and its associated process. 
Chapter II also introduces the motivations to implement LISI in term of information 
systems’ interoperability. 

Chapter III illustrates how LISI process works by discussing the development and 
use of the LISI prototype tool in its application to Army Systems. Next it examines the 
LISI user friendliness and its security. 

Chapter IV provides analysis of the primary research question as whether LISI 
can improve DOD C4I systems’ interoperability. The reports from the LISI pilot 
assessment conducted by MITRE in 1999 and the final analysis assessed by HTIO 
Interoperability in 2001 were used for the analysis. 

Chapter V summarizes the findings of the research, answers the research 
questions, and presents recommendations for further research and study. 

G. BENEFITS OF THE S TUDY 

It is my hope that this study will be used to continue the evolution, refinement, 
application, and institutionalization of LISI because applying LISI may benefit the 
following: 

Joint Mission Planners - who need to be able to use LISI in context with mission area 
assessments to facilitate the development and dissemination of interoperability 
requirements for new systems. 

Program Managers - who need to be able to use LISI to identify potential interoperability 
problems early in the analysis phase of system development (the period during which 
implementation choices are made) rather than discovering issues after system fielding. 
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Command Architects - who need to be able to use LISI to assess the interoperability of 
systems in an existing or planned architecture, to evaluate alternative strategies, to 
improve interoperability, and to meet the mission and operational requirements. 

Joint Task Force (JTF) Planner - who needs to be able to use LISI to assess the 
interoperability of existing systems prior to deployment, including the rapid identification 
and resolution of interoperability shortfalls. 

System Evaluators - who need to be able to use LISI during laboratory or field 
experimentation to determine the impact of various interoperability levels on mission 
effectiveness. 
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II. WHAT IS LISI? 


A. INTRODUCTION 

Although LISI was initiated in 1993, it is still foreign to the majority of the 
program management community. In order to examine how LISI can improve DOD C4I 
systems’ interoperability, it is prudent to know exactly what LISI means and what its 
functionalities are and how LISI actually works. This Chapter will exam the “What’s” 
and Chapter III will discuss the “How’s.” The following sections give a description and 
background information on LISI, its evolution, its elements, and its benefits of 
implementation. Also, other DOD Information Technology (IT) initiatives are discussed 
in relation to LISI. 

Much of the information presented in this chapter was extracted and summarized 
from several information interoperability and LISI related reports and briefings. The 
reports include GAO report of March 1998 on Joint Military Operations, C4I 
Surveillance and Reconnaissance (C4ISR) Architectures Working Group Final Report of 
14 April 1998, and Pilot Assessment of the LISI Using Components of the ABCS Final 
Report of November 1999. The briefings include Army LISI Overview Briefings of 12 
October 2000 from Department of Army Military Office - Directorate of Integration 
(DAMO-DOI); Defense Information Systems Agency - Joint C4 Program Assessment 
Tools (DISA-JCPAT); Office of the Secretary of Defense - Assistant Secretary of 
Defense Command, Control, Communications and Intelligence (OSD-ASD C3I); and the 
Army. Detailed information from each of these Army briefings is now available at 
http://svsarch.armv.mil/LISI Inspector/references. 

B. LISI DEFINITION AND FUNCTIONALITIES 

LISI can be defined as a formal Reference Model, an assessment 
implementation of the interoperability maturity model, and a structured process for 
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improving interoperability between varied information systems . Simply said, LISI is 
a maturity model and interactive process for assessing and improving interoperability. 

The LISI tool provides an automated, web-based interoperability assessment 
capability. It provides interoperability analysis, such as interoperability profiles for 
C4ISR information technology (IT) systems, interface status between systems at nodes or 
within a mission area, and end-to-end interoperability levels for a specific mission. It is 
intended to support system of systems interoperability and requirements assessments 
across the Department of Defense. 

By dissecting the above definition and description, the functionalities of LISI can 
be summarized as: (Levine, 2000) 

a. A discipline for improving interoperability (It is a formal process.) 

b. A work ethic for improving interoperability (It requires collective 
commitment to a process.) 

c. A structured approach for reaching agreement about what 
capabilities are needed to improve interoperability (It involves 
common understanding of how to implement a process.) 

d. A measure of performance for interoperability that characterizes 
what capabilities can be performed between systems (It is expressed in 
“levels” of increasing sophistication.) 

However, LISI is not a prescription for guaranteeing interoperability. The heart 
of the LISI concept is the formulation of a system “profile” which was created by LISI. 
The “profile” may become the common denominator for determining interoperability 
between C4 systems but it is certainly not a prescription for guaranteeing 
interoperability. The profile is an indicator and not an absolute. The reason is simply 
that “garbage in and garbage out” and the system can only be as good as the data. The 
questionnaires used for the process may not be inclusive of all pertinent interoperability 
elements required. Furthermore, the person entering the data for the questionnaires might 
be not knowledgeable enough to answer all the right questions with the correct answers. 
Therefore, LISI is a tool to examine, to compare, but not to guarantee the interoperability 
of IT systems. 
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C. MOTIVATION OF INITIATING AND IMPLEMENTING LISI 


1. Achieve Information Superiority 

The Chairman of the Joint Chiefs of Staff advanced a bold vision of American 
war fighting capabilities, Joint Vision 2010, which has become the conceptual template 
for how we will channel the vitality of our people and leverage technological 
opportunities to achieve new levels of effectiveness in joint war fighting. (Shalikashvili, 
1997) At the heart of the joint vision is information superiority - the ability to collect 
and distribute to U.S. forces throughout the battlefield an uninterrupted flow of 
information, while denying the enemy’s ability to do the same. (Cohen, 1997) The 
Quadrennial Defense Review (QDR) of May 1997 also identified information 
superiority as the backbone of Military Innovation, and noted that the Revolution in 
Military Affairs (RMA) centers on developing the improved information, and command 
and control capabilities needed to significantly enhance joint operations. 

In order to provide uninterrupted flow of information during the military joint 
operations, the C4I systems must be “interoperable.” Unfortunately, the military services 
have a long history of interoperability problems during joint operations. LISI was 
initiated in 1993 after the difficulties of basic interoperability experienced during the 
Persian Gulf War in 1991. The information superiority envisioned by Joint Vision 2010 
in 1997 further challenged the development and implementation of LISI. 

2. Support Joint Task Force (JTF) 

The JTF that fights the next conflict does not exist until the need arises. Its 
approach to information management and the set of electronic information systems will 
be based in large part on which Services is in charge of the operation. Though all 
Services provide their essential set of automated “tools,” the particulars of which ones, 
how many, where they are located, etc. are all dependent on the situation and the 
decisions of the assigned Service Commander or someone in his chain of command. 
Determining how these systems are pulled together to accomplish a joint mission is of 
one of the major challenges facing the development of information system architectures 
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throughout DOD. Information systems built to meet specific Service requirements must 
still provide for the appropriate level of C4ISR interoperability to meet joint 
requirements. Therefore, understanding how much interoperability is required is a key 
consideration that must be accounted for when designing constructing, and deploying IT 
architecture. 

In order to support JTF, LISI has been designed to focus on defining and 
assessing systems against increasing levels of sophistication for system-to-system 
interaction. These levels describe the stages of process improvement for interoperability 
and are documented in the form of an Interoperability Maturity Model. 

3. Compliance With Information Technology Management Reform Act 
(ITMRA) 

The ITMRA of 1996 (Public Law 104-106), also know as the Clinger-Cohen Act, 
requires the Federal government to develop “a process and procedure for establishing 
goals for improving the efficiency and effectiveness of government agencies’ operations 
and the ability to deliver goods and services to the public using information technology. 
The goals must be “measurable.” (C4ISR, 1998) 

The ITMRA further states that, “the director shall encourage the use of 
performance-based and results-based management.” Before LISI, there were no widely 
accepted performance-based and results-based standards for interoperability. Now LISI 
directly supports the development of IT architectures within the context of ITMRA by 
assessing the level of interoperability required and attained between systems. (C4ISR, 
1998) 


4. Assist in Certifying Process And Improving C4I systems’ 
Interoperability 

GAO identified several weaknesses in DOD’s process for certifying C4I systems’ 
interoperability in its March 1998 report. The Joint Staff’s Director for C4 systems (J-6) 
is assigned primary responsibility for ensuring compliance with certification requirement. 
Certification is intended to help provide the war fighter with C4I systems that are 
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interoperable and to enable forces to exchange information effectively during a joint 
mission. However, DOD did not have an effective process for certifying existing, newly 
developed, and modified C4I systems for interoperability. As a result, many C4I systems 
have not been certified for interoperability and DOD did not even know how many 
require certifications. (GAO, 1998) 

GAO warned that improving ways of complying with the certification process 
alone would not solve all of the issues related to interoperability and a number of 
initiatives had to be continued. LISI was one of the initiatives mentioned in the report. 
GAO indicated, “DOD’s 1993 LISI initiative is to improve C4 and intelligence systems’ 
interoperability. System developers are to use this tool to assess interoperability, 
determine capabilities needed to support system development, and determine the degree 
of interoperability needed between C4I and other systems.” (GAO, 2000) 

5. Become A Mandatory Interoperability Evaluation Tool 

In recognizing that the Army lacks a means to quickly assess System-Of-Systems 
(SoS), the Director of Information Systems for C4 and the Military Deputy to the 
Assistant Secretary of the Army (Acquisition, Logistics and Technology) mandated on 
their joint memorandum of 15 August 2000 that the Headquarters of Department of Army 
(HQDA) to employ LISI framework and its associated interoperability assessment tool to 
address SoS interoperability. 

The memorandum further explained the rational for mandating of implementing 
LIST Chairman Joint Chiefs of Staff Instruction, 62I2.0IB, dated May 8, 2000, calls for 
the development of the Command, Control, Communications, Computers and 
Intelligence Support Plan (C4ISP). A C4ISP must be developed for all systems that 
exchange information in any electronic form. The technical data stored in LISI, along 
with LISI output products, satisfy the C4ISP requirements for a technical architecture 
profile and view. Therefore, using LISI to meet this requirement gives the Army a 
standard, mature process to collect, archive, and share this information. (Cuviello, 2000) 
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D. EVOLUTION OF LISI 


LISI has come a long way to today’s pilot assessments and implementation. 
MITRE Corporation has been the developer of the LISI process and its associated 
software application since the inception of LISI in 1993. It is a process that has evolved 
since its inception in 1993. The Intelligence Systems Council (ISC) conducted the initial 
concept and process. Then Integration Task Lorce (ITL) expanded and detailed the LISI 
concept and scope significantly in 1996. During 1997, Architectures Working Group 
(AWG) conducted the third phase, proof of concept. In 1999, the pilot assessments were 
conducted and the Initial Operational Capability (IOC) 2000 followed. A snapshot of the 
evolution is summarized in figure 2-1 below. (DOI, 2000) 



Ligure 2-1. Evolution of LISI, from (DOI, 2000) 
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1. Exploratory Phase, Intelligence Systems Council (ISC), 1994 (Birth of 
the Concept) 

In 1993, the ISC was at the end of its wits. U.S. military force deployments 
continued to indicate that the automated information systems used by the military 
departments did not interoperate well, if at all. Individual organizations and program 
managers had their own interpretations of “interoperability.” When consensus could not 
be reached, the member organizations turned to the formal definition. According to the 
Joint Publication 1-02, DOD Dictionary of Military and Related Terms, interoperability 
is defined as follows: 

The condition achieved among communications-electronic systems or 
items of communications-electronic equipment when information and 
services can be exchanged directly and satisfactorily between them 
and/or their users. The degree of interoperahility should he defined 
when referring to specific cases. (DOI, 2000) 

The ISC participants focused heavily on the last sentence in the DOD definition, 
and recognized the need to define “degrees” or ‘levels” of interoperability that could 
accomplish the following: 

a. Serve to discriminate major variances in required Joint information transactions 
and sophistication from one system to another. 

b. Provide for a simple construct to facilitate cross-organizational coordination. 

c. Enable interoperability assessments of intelligence and Command and Control 
(C2) systems that need to interact. 

d. Serve to guide or discipline interoperability improvement actions. (DOI, 2000) 

2. Analysis Phase, C4ISRITF, 1995-1996 (DOD Endorsement) 

In October 1995, the Deputy Secretary of Defense tasked (ASD) (C3I) to define 
and develop better means and processes to ensure C4I capabilities most effectively meet 
the needs of our warfighters. In response to this tasking, the C4ISR ITF was established 
and an Integrated Architectures Panel (lAP) was created to engineer a C4ISR architecture 
process and identify ways to improve systems interoperability. The lAP advocated the 
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concept of “Level of Interoperability” as mechanism for C4ISR practitioners to negotiate 
an affordable and technically appropriate capability mix among C4ISR systems intended 
to interoperate, and to ensure Joint interoperability. Finally, The Under Secretary of 
Defense Acquisition and Technology (USDA&T), the Assistant Secretary of Defense 
(ASD) (C3I), and Vice Chairman of the Joint Chiefs of Staff (VCJCS), endorsed the 
levels of interoperability concept and tasked the ASD (C3I) to lead a follow-on effort to 
“define and use Levels of interoperability” (DOI, 2000) 

3. Proof of Concept Phase, C4ISR AWG, 1997-1998 (Architectural 
Framework Integration) 

Building upon the recommendations of the C4ISR ITF and the LISI report 
published in June 1996, MITRE Corporation was tasked to continue to work with the 
C4ISR community to further evolve LIST In an effort to engage DOD community 
participation, an Interoperability Panel was formed in January 1997 as part of the C4ISR 
AWG sponsored jointly by the ASD (C3I) and the Joint Staff (JS) J-6. (DOI, 2000) 

4. Application And Evaluation Phase, DOD, 1999-2000 (Pilot 
Assessments) 

At the request of the Army Systems Engineering Office with coordination of the 
Horizontal Technology Integration Office, PEO C3S, MITRE undertook the pilot 
assessment of EISI. In November 1999, MITRE published their pilot assessment report 
of the EISI using components of the ABCS. This report discussed the development and 
use of the EISI prototype tool in its application to Army Systems. Software development 
questionnaire building and prototype installation are described. Then the prototype’s 
utility is discussed through its application to the Army’ ABCS 4.0 component systems. 
(DOI, 2000) 

5. Initial Operational Capability (IOC), DOD, 2000-present (IOC 2000) 

DOI hosted a kickoff meeting and provided training on the EISI tool in October 
2000 in response to Eieutenant General Peter M. Cuviello and Eieutenant General Paul J. 
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Kern’s memorandum directing the mandatory use of LISI. The IOC participation 
includes Army Materiel Command (AMC) soldier & Biological Chemical Command 
(BCC), AMC Tank Automotive Command (TACOM), PEO Aviation, PEO Standard 
Army Management Information System (STAMIS), and PEO Theater Missile (TM). 
(DOI, 2000) 

However, the EISI is a living entity and will be constantly evolving. In concert 
with technological advances in information systems and changes in the methods by which 
enterprises employ information systems technology in support of their operations, the 
continuing evolving of the EISI is anticipated. 

E. THE ELEMENTS OE LISI CAPABILITIES MODEL 

In order to evaluate whether the EISI can improve IT interpretabilities, the 
understanding of the planned EISI Capabilities Model is essential. A capabilities model, 
such as that defined within EISI, is commonly described as a set of concepts, entiies, 
interfaces, and diagrams that provides common ground for understanding and 
comparisons. It does not provide a specific system design or prescription for 
implementation, but it does define a common set of services and interfaces for building 
specific designs. In a similar manner, the EISI Capabilities Model does not prescribe 
specific implementation choices necessary to attain a level of interoperability. Instead, 
EISI draws heavily from commonly existing organizational directives and mandates. In 
the case of DOD, these implementation choices are derived from related sources such as 
the Joint Technical Architecture (JTA), Defense Information Infrastructure (DII) 
Common Operating Environment (COE), and Shared Data Environment (SHADE). 
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LISI Capabilities Model 

Figure 2-2, from (OSD, 2000) 
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1 . 


The “Level” Concept 


a. Level 0: Isolated (Stand Alone) 



Figure 2-3. Level 0: Isolated Interoperability in a Manual Environment, 

from (C4ISR, 1998) 


Figure 2-3 represents Level-0 interoperability. Level 0 is described as 
isolated interoperability in a manual environment. The key feature of Level 0 is human 
intervention to provide interoperability where systems are isolated from each other. 
Level-0 systems need to exchange data or services, but cannot directly interoperate. The 
lack of direct, electronic connectivity may exist solely due to differing security or access 
- control policies, or it may be a lack of physical connection between two systems. 
(C4ISR, 1998) 


b. Connected (Peer to Peer) 



Telnel, FTP, 
E-mail, Chatter 



Figure 2-4. Level 1: Connected Interoperability in a Peer-to-Peer Environment, 

from (C4ISR, 1998) 


Figure 2-4 represents LISI Level-1 interoperability. Level 1 is described 
as connected interoperability in a peer-to-peer environment. The key feature of Level 1 
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is physical connectivity providing direct interaction between systems. Level 1 systems 
have an established eleetronie link eharacterized by separate peer-to-peer eonnections. 
At this level of interoperability, the interactions are between diserete systems. Links ean 
loeally support simple file exchanges between systems. The type of files exehanged is 
typieally homogeneous in eontext (e.g., text-only file, a bitmap file). (C4ISR, 1998) 


Distributed (Functional) 


c. 



Figure 2-5. Level 2: Functional Interoperability in Distributed Environment, from 

(C4ISR, 1998) 


Figure 2-5 represents Level-2 interoperability. Level 2 is deseribed as 


functional interoperability in a distributed environment. The key feature of Level 2 is the 
ability of independent applications to exchange and use independent data components in 
a direet or distributed manner among systems. Level-2 systems must be able to exchange 
and process eomplex (i.e., heterogeneous) files. These files eonsist of items sueh as 
annotated images, maps with overlays, and multi-media or hyper-linked documents. The 
systems are generally eonnected to multiple systems on local networks. A key capability 
provided by systems or applieations, at the top end of this level, is the ability to enable 
and provide web-based access to data. (C4ISR, 1998) 
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d. Integrated (Domain) 



NIDR, Common Displays, Shared 
Applications & Data, ... 

Data 




Applications 



Figure 2-6. Level 3: Domain Interoperability in an Integrated Environment, from 

(C4ISR, 1998) 


Figure 2-6 represents Level-3 interoperability. Level 3 is described as 
domain interoperability in an integrated environment. The key feature of Level 3 is a 
domain perspective that includes domain data models and procedures where data is 
shared among the independent applications that may begin to work together in an 
integrated fashion. Level 3 is characterized by multiple application-to-application 
interactions. Systems and applications are interconnected, but generally operate on a 
single functional set of data (e.g., intelligence, C2, logistics). Implementation at this 
level usually has only a localized view of the distributed information space and cross only 
one operational or functional domain. (C4ISR, 1998) 
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e. 


Networked (Enterprise) 



Figure 2-7. Level 4: Enterprise Interoperability in a Universal Environment, from 

(C4ISR, 1998) 

Eigure 2-7 presents Eevel 4 interoperability. Eevel 4 interoperability is 
described as enterprise interoperability in a universal environment. The key feature of 
Eevel 4 is a top-level perspective that includes enterprise data models and procedures, 
where data is seamlessly shared among the applications that work together across 
domains in a universal access environment. Eevel 4 is the ultimate goal of information 
systems seeking interoperability across functional activities and informational domains 
(e.g.. Intelligence, C2, and Eogistics). At this enterprise level, information is shared 
globally through distributed information architecture. Applications and systems operate 
as necessary across all the functional data domains. The ‘virtual’ workspace uses shared 
applications operating against an integrated information space. Eevel 4 represents the 
capabilities necessary to achieve concepts proposed in DOD’s Joint Vision 2010 
documents. (C4ISR, 1998) 

2. The “Attributes” - PAID 

EISI categorizes the various aspects of information systems interoperability in 
terms of four comprehensive, closely interrelated attributes: Procedures, Applications, 
Infrastructure, and Data (PAID). They are the enablers of interoperability and its 
various maturity levels. Individually, these attributes are like pieces of a puzzle, each 
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possessing its own identity (shape) and purpose (content). When joined together 
(pictured in Figure 2-8), these attributes can be represented as a complete circle whose 
“circumference” encompasses the entire realm of interoperability issues and 
considerations and whose “area’ defines the full set of conditions, characteristics, and 
criteria necessary for achieving interoperable environments. Consideration and 
understanding of the interrelationships between all the PAID attributes are critical for 
moving interoperability beyond the simple connection between systems. In order to 
assess interoperability completely, it is necessary to apply PAID throughout each of the 
levels described in section 2.5.1. 
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Figure 2-8. The PAID Attributes, from (Levine, 2000) 


a. Procedures 

It encompasses the many forms of documented guidance and operational 

controls that affect all aspects of system development, integration, and operational 

functionality. This attribute addresses specific implementation options selected for a 

system or systems as well as overarching standards and architecture guidance for the 

given enterprise. It encompasses operational and functional program development 

guidance as well as technical and system architecture standards (such as hardware, 

system software, communications data, and applications). Items that make up the 
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procedures attribute are organized into four major categories that span the levels of 
interoperability 

a. Standards: Technical Standards, Technical Architectures, and Common 

Operating Environment (COE) 

b. Management: Mission, Doctrine, Systems Requirement Definitions, 

Installation, and Training 

c. Security Policy: Classified, Unclassified, or Secret 

d. Operations: Network, E-Mail Servicing, and Bandwidth Considerations 

(C4ISR, 1998) 

b. Applications 

It encompasses the fundamental purpose and function for which any 
system is built, that is, its mission. The functional requirements specified by users to 
perform an operational activity are the very essence of the software application. Whether 
it is the need to do simple word processing or perform advanced nuclear targeting, the 
functions being accomplished and the applications that support them represent the 
system’s capabilities to the user. Eor interoperability to occur effectively, similar 
capabilities or a common understanding of the shared information must exist between 
systems; otherwise, users have no common frame of reference. (C4ISR, 1998) 

c. Infrastructure 

It supports the establishment and use of a “connection” between systems 
or applications. This connection may be a simple, extremely low-level exchange, or it 
could consist of wireless Internet Protocol (IP) networks, operating at multiple security 
levels. These two examples point out the breadth of the communications and hardware 
aspects. Infrastructure also includes “system services” that facilitate systems operations 
and interactions. These are items such as communication protocol stacks and object 
request brokers that are used by functions to establish and affect interactions between 
systems. The security devices and technical capabilities that are used to implement 
security procedures also make up a part of infrastructure. (C4ISR, 1998) 
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d. Data 

It focuses on the information processed by the system. This attribute deals 
with both the data format (syntax) and its content or meaning (semantics). It includes all 
the forms of data that support every level of a system’s operations, which is from its 
operating system and communications infrastructure to the full set of end-user 
applications. The data attribute embodies the entire range of information styles and 
formats: free text, formatted text, databases (formal and informal), video, sound, 
imagery, graphical (map) information, etc. As such the data attribute is understandably 
the most critical aspect of attaining systems interoperability. It is within this attribute 
where much of today’s focus and work towards building interoperable systems is taking 
place, such as defining standard file formats, standards of databases, and data definitions. 
(C4ISR, 1998) 

F. LISI AND DOD IT INITIATIVES 

There are numerous DOD initiatives that are focused on one or more aspects of 
interoperability. Each initiative lends an important contribution to the process of 
improving interoperability. What is lacking is a way to pull all of these together to give 
meaning to statements about interoperability. LISI is the key tying it all together, using a 
uniform capability- model structure and discipline, and a comprehensive coverage of all 
key aspects of the PAID attributes as discussed in section 2.5.2. LISI works to track 
these initiatives and their associated constructs, interrelate them using the family of LISI 
models, leverage their findings and positions into the LISI assessment process, and 
provide the integrated basis for coordinating these initiatives to maintain consistency and 
currency. The examples of how LISI integrates and interrelates to these DOD initiatives 
are summarized in the following. (C4ISR, 1998) 
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Figure 2-9 Cross Mapping of JTA and LISI, from (C4ISR, 1998) 


The JTA has been explicitly incorporated into the LISI process. Figure 2-9 
presents an extract from the detailed mapping of LISI and the JTA. The LISI Capabilities 
Model includes the relevant standards from the JTA. Those PAID capabilities and 
implementations of each LISI-assessed system or application that comply with JTA 
standards are identified as such in the system’s Interoperability Profile. Each entry in the 
LISI Options Tables that is also in the JTA is identified as such. Therefore, LISI can 
identify which implementation of any system or application conforms to JTA standards 
and which implementations are outside the accepted standards found within the JTA. 
(C4ISR, 1998) 


2. Defense Information Infrastructure (DII) Common Operating 
Environment (COE) 

Although LISI and DII COE differ significantly in terms of purpose and scope, 
they are complementary initiatives. The DII COE focuses on the portability of software 
and the configuration management of application-to-operating environment interactions 
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and LISI focuses on the system-to-system interactions that characterize interoperability. 
However, twenty percent of the DII COE Integration and Runtime Standards (I&RTS) 
Compliance Checklist questions map directly into LISI. These questions relate to topics 
such as infrastructure implementations, applications, security issues, and naming 
conventions. Figure 2-10 presents a portion of the complete DII-to-LISI crosswalk table 
in order to demonstrate the mapping process. (C4ISR, 1998) 
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Figure 2-10. Cross-Mapping of DII COE and LISI, from (C4ISR, 1998) 

3. DII Master Plan 

The DII Master Plan is a broad document meant to insure that an infrastructure is 
in place within the DOD to allow for the establishment of a common link between 
systems as they develop. The ability of systems to work within the Information 
Infrastructure defined by this plan is critical to ensuring interoperability. Therefore, 
initiatives focused on implementation of the DII Master Plan should be closely 
coordinated with LISI. In particular, the way that LISI captures the various aspects of the 
infrastructure that are included within the scope of the DII Master Plan on a “level-by- 
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level” basis should be closely synchronized with Master Plan implementation planning 
efforts. 

4. Shared Data Environment (SHADE) 

SHADE is representative of the effort within the DOD C4ISR community to 
reach agreement on common data models for systems. It is a fairly recent initiative, and 
is not currently as well defined as the DII COE. The SHADE effort is critical to defining 
those aspects of data needed for interoperability maturity. A preliminary review of 
SHADE was performed to determine that the EISI process, especially the data attribute of 
PAID, is consistent with SHADE’S direction. EISI does not attempt to define data 
models, but merely records their usage. Deliberate and continuous coordination must be 
conducted to ensure that USI and SHADE are tightly integrated as they both evolve. 
(C4ISR, 1998 

5. Joint Battle Center (JBC) 

Maintaining the currency of capabilities and implementation captured by EISI is 
critical as technical standards continue to evolve and as commercial industry continues to 
release new technologies. The EISI options tables that identify the numerous alternatives 
available for implementing the general capabilities profiled in the EISI Capabilities 
Model must be continuously updated. This update process must be performed in close 
coordination with the operational user community, industry, and the acquisition 
community. The JBC is an organization where many of these groups come together to 
examine system performance and interoperability in context with Joint Task Eorce (JTE) 
mission operations. The collective insight these groups bring makes the JBC an ideal 
forum for capturing these integrated views using the EISI construct and process. (C4ISR, 
1998) 


6. Joint Interoperability Test Command (JITC) 

The JITC is faced with the daunting task of testing and certifying DOD information 
systems. The sheer number of systems makes it impractical to test every possible 
system-to-system combination. By looking at products produced by EISI, particularly 
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the various system interoperability profiles, critical interfaces between systems can be 
identified. The LISI products, in conjunction with architecture information and JBC 
experimentation results, serve a ‘screening” function in pinpointing what specific aspects 
of system to-system interoperability are most critical or most at-risk. These are the areas 
where testing of systems should focus, where compliance and surety are most important, 
and where testing will yield a high payoff. The JITC could use the results of LISI 
assessments to build Test and Evaluation master Plans (TEMPs). These plans will be 
able to validate the particular implementations that are most critical to interoperability 
with other systems. (C4ISR, 1998) 

G. BENEFITS OF IMPLEMENTING LISI 

Before EISI, there was no widely accepted performance-based or results-based 
standard for interoperability. Now EISI directly supports the development of IT 
architectures within the context of ITMRA by assessing the level of interoperability 
required and attained between systems. In addition to being able to tie all DOD IT 
initiatives together, using a uniform capability-model structure and discipline, and a 
comprehensive coverage of all key aspects of the PAID attributes, several benefits of 
implementing EISI can be identified as the following. (AWG, 1998) 

1. Quantify Interoperability 

EISI revokes the ambiguity in determining levels of interoperability. In addition 
to an overall rating, EISI measures interoperability along each of its four axes, PAID, and 
provides the manager with a formal scorecard for interoperability through the common 
reference model. The EISI model identifies the stages through which systems should 
logically progress, or “mature’, in order to improve their capabilities to interoperate. 

EISI also considers five increasing levels of sophistication regarding system interaction 
and the ability of the system to exchange and share information services. Each higher 
level represents a demonstrable increase in capabilities over the previous level of system- 
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to-system interaction. By quantifying interoperability, LISI provides a common DOD 
basis for requirements definition and for incremental system improvements. 

2. Aid in Establishment of Appropriate Level of Interoperability 

LISI saves managers money. Not all projects require the same level of 
interoperability. By establishing a common set of definitions and operating assumptions 
about interoperability, LISI allows decision-makers to specify appropriate levels of 
interoperability. A squad level communication device has fewer requirements for 
interoperability than does a national level collection and processing center, but without 
some way of specifying an appropriate level, the manager is left trying to guess and 
he/she perhaps overestimates the level of interoperability. 

3. Provide Fully Integrated View 

LISI looks at the entire program to include policies and procedures for system 
implementation. It is not limited to the technical view. 

4. Track Interoperability Level Throughout Life Cycle 

LISI helps programs throughout their lifecycles. During the design phase, LISI 
helps managers identify gaps in interoperability between proposed and existing systems. 
Managers can use the LISI “scorecard” to track their project’s interoperability level 
throughout system development. LISI suggests economical fixes for interoperability 
gaps. 


5. Serve As Management Tool 

LISI will benefit all communities from the Program Managers (PMs) to 
assessment and oversight bodies. The LISI interoperability assessment process provides 
expedient and collaborative mechanisms and common metrics for DOD to assess current 
interoperability postures, to identify quick-fix options, to develop strategies for 
achieving higher states of interoperability maturity, and for providing timely feedback to 
DOD standards bodies. 
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The joint mission planners can use LISI in context with mission area assessments 
to facilitate the development and dissemination of interoperability requirements for new 
systems. The PMs can use LISI to identify potential interoperability problems early in 
the analysis phase of system development rather than discover issues after system 
fielding. Also, the command architects can use LISI to assess the interoperability of 
systems in an existing or planned architecture and evaluate alternative strategies to 
improve interoperability to meet the mission and operational requirements. 

H. CHAPTER SUMMARY 

LISI is a maturity model and interactive process for assessing and improving 
interoperability. It is a discipline, a work ethic, a structured approach, and a measure of 
performance for improving interoperability but it is not a prescription for guaranteeing 
interoperability. 

LISI was initiated in 1993 because the military services have a long history of 
interoperability problems during joint operations. The motivations for LISI to continue 
for developing, prototyping, and implementing are multifaceted. To name a few, the 
motivations are to achieve information superiority, to support JTF, to comply with 
ITMRA, to assist in the certifying process and improving C4I systems’ interoperability, 
to implement GAO recommendations, and to become a mandatory interoperability 
assessment tool. 

The “Levels” and the “Attributes” are the essential elements of LISI. LISI 
considers five increasing levels of sophistication with respect to exchanging and sharing 
information and services. Each higher level represents a demonstrable increase in 
capabilities over the previous level of system-to-system interaction. This increase is 
expressed in terms of PAID - the Procedures imposed by information management, the 
capabilities of Applications that act on that data, the type of Infrastructure required, 
and the nature of Data transferred. 

There are several DOD initiatives to improve information interoperability, why 
LISI? Evidently, EISI is the key tying all the initiatives all together using a uniform 
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capability- model structure and discipline, and a comprehensive coverage of all key 
aspects of the PAID attributes. In addition, LISI will benefit the joint mission planners, 
the program managers, command architects, and all information system communities to 
establish an appropriate level of interoperability, to quantify interoperability, to assess, 
and to improve system interoperability. 
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m. HOW DOES LISI PROCESS WORK? 


A. INTRODUCTION 

A web-based tool, Inspector 1.0, has been used to support the interoperability 
assessment that the LISI system provides. As discussed in chapter II, LISI is a maturity 
model and interactive process for assessing and improving interoperability. The 
Inspector has been developed to provide such processes as determining interoperability 
needs, assessing the ability of specific information systems to meet those needs, and 
selecting pragmatic solutions and transition paths for achieving higher states of capability 
and interoperability. 

Inspector receives inputs via a system survey questionnaire. The LISI survey 
contains a questionnaire that can be completed through a web interface to capture 
relevant data about a system. The tool then performs the mapping of the capabilities 
against the model, and calculates the resulting profile and level. Users register system 
characteristics by selecting the appropriate responses to the questions. Questionnaire 
responses are directly shared within the database and stored in a table from which data 
can be used to create a set of products (outputs). Hopefully, the interoperability 
managers can use the LISI reports to identify gaps, shortfalls, and improvement strategies 
and agreements of system interoperability. 

The access to the LISI Inspector is password controlled and the data privacy in the 
LISI Inspector is highly protected. The first step in registering a system is to acquire a 
user account from the System Administrator ^A). The LISI tool is web based and is 
intended to be user friendly. It completed a series of major enhancements during FY 99 
that resulted in several incremental “versions,” each representing a major increase in 
either software performance and /or a significant expansion/enhancement of the survey 
questionnaire. Inspector currently contains approximately 220 questions covering a wide 
range of topics. These questions now contain over 3,000 possible answers that are 
currently composed of over 12,000 individual response fields. (MITRE, August 2000) 
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How LISI works through Inspector will be discussed in more detail throughout 
this chapter. A capsule view of LISI can be depicted as the following, figure 3-1. 
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Figure 3-1. A Capsule View of the LISI Assessment Process, from (MITRE, August 
2000 ) 


B. LISI TOOL - INSPECTOR 1.0 


Inspector 1.0 is a web-based tool for capturing, manipulating, and analyzing 
information technology (IT) system characteristics in context with any x-y coordinate- 
based reference model. In addition to DII COE Runtime Environment Compliance 
Eevels and International Standard Organization -Open Systems Interconnection (ISO- 
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OSI) Protocol Stacks, LISI Capabilities Model is one of the reference models that 
Inspector 1.0 processes. 

Inspector receives inputs via a system survey questionnaire. Questionnaire 
responses are directly shared within the database. As a result, data being entered into any 
of the specific surveys (e.g., LISI) is automatically entered into the other surveys (e.g., 

DII COE, OSI). Inspector also provides the ability to import and export data. Data 
extracts are constructed as comma-delimited text files that can be sent using most 
standard email programs. 

In order to decide whether LISI can improve interoperability, it is important to 
understand what its tool is all about and how the tool works. A brief overview of 
Inspector I.O will be examined in term of its evolution, functionality, hardware and 
software requirements, and access procedures as follows. 

1. Inspector 1.0 Evolution - Software Enhancements and Questionnaire 
Revisions 

Inspector I.O includes five system surveys, 1) LISI survey, 2) DII COE 
Integration and Runtime Standards (I&RTS) version 3.1 Survey, 3) DII COE I&RTS 
version 4.0 Survey, 4) Open Systems Interconnection (OSI) Survey, and 5) US Message 
Text Eormat (USMTE) Eunctional Survey. Each survey has its own structure and 
question set. Both Versions 3.1 and 4.0 DIICOE Surveys cover the I2-to-13 functional 
areas identified in I&RTS versions. The OSI Survey contains a structure based on the 
OSI Reference Model (including major protocol suites). The USMTE Eunctional Survey 
covers each USMTE functional area. The LISI Survey focuses on the four 
interoperability attributes: Procedures, Applications, Infrastructure, and Data. 

Inspector’s evolution from a prototype to an operational capability has been 
driven primarily by expansion of the LISI Survey. The DII COE and the OSI Survey are 
both relatively new items. The USMTE Survey is a restructuring of USMTE messages 
by functional area (they are listed in the LISI Survey by USMTE message number). In 
all cases where a response option is common to questions in multiple surveys, when that 
response is checked in one survey, it will automatically be checked in all other applicable 
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surveys. The OSI, USMTF, and some of the DII COE Surveys contain questions with 
response options in common with each other and with the LISI Survey. (MITRE, August 
2000 ) 


2. Inspector 1.0 Functional Components 

Inspector provides functionality in several key areas, including database 
management, user input of system data, customization and use of the survey 
questionnaire, and output and presentation of reports for comparative analysis of the 
system data. Inspector provides a database management environment to manage 
information concerning both the systems being evaluated and the information contained 
within the questionnaires and their relationships to the x-y coordinate-based reference 
models, such as EISI Reference Model. The system information includes administrative 
data such as system name, organization, point of contact, and version. It also includes a 
compilation of the interoperability characteristics of each system as captured through use 
of the system surveys. (MITRE, August 2000) The Inspector’s major functional 
components are: 


a. Survey Questionnaire 

It is the survey interface portion of Inspector that allows users to input 
information describing their systems through a questionnaire. 

b. Multiple Survey Capability 

The data calls can exploit the existing data since Inspector is configured to 
provide credit for a single answer across all appropriate questionnaires. 

c. Reports 

Inspector generates reports that reflect the information describing the 

systems. 
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d. Questions Builder 

Inspector currently provides a means for creating new questions through 
the use of an administrative tool built to operate within a standard web-browser. 

e. Data Exchange 

With the delivery of Inspector 1.0, organizations are able to import and 
export system data using a common process. If this integration is accomplished, the 
information about IT systems can then be easily transported between Services and 
Agencies using standard Inspector database extracts. 

3. Inspector 1.0 Hardware and Software Configurations 

Certain hardware and software configurations are required for installation and 
operational use of Inspector. According to MITRE Corporation, in its Inspector Version 
1.0 Description of August 2000, the following components and services must be installed 
before Inspector can operate correctly: 

a. Hardware 

Although Inspector can be successfully operated on less capable hardware 
system configurations, the software demands of Windows NT/Server and the Cold Fusion 
Server are likely to result in unsatisfactory performance. The recommended hardware 
configuration is: 

• 400 MHz Pentium Processor 

• 256 Mbs RAM (512 Mbs recommended) 

• 500 Mbs-i- free space 

• CD-ROM or ZIP drive available to the server 

b. Software 

Presently, Inspector has been verified and configured for Beta testing on 
only one operating system. The Inspector software was written in a 4GL that is already 
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compatible with many other Unix environments but verification testing has not been 
conducted. The current validated operating systems are Windows NT Workstation or 
Server 4.0 Service Pack 4 or higher. 

Some commercial software packages are needed in order for the Inspector 
software to function such as Cold Fusion 4.0 Server (Allaire Corp, 
http://www.allaire.com) and a Web Server compatible with Cold Fusion (Microsoft IIS 
4.0 or Peer Server and Personal Web Server, Netscape Enterprise and FastTrack Servers, 
Apache). The minimum versions of useable web browsers that are verified to work 
properly with Inspector are Netscape 4.0+ or Microsoft Internet Explorer 4.0+. However, 
the Netscape 4.0+ is the more reliable browser since Microsoft Internet Explorer 4.01+ 
has known problems such as timeout errors during report generation. 

One of the capabilities provided within Inspector is an ability to produce 
an extract and perform an automated update of architecture diagrams for import and use 
in NetViz (soon to Aperture, an optional commercial software package that have been 
certified). These products are only available at present for Microsoft Windows-95+ 
configured machines. Currently, individual workstation licenses are required for 
operating these applications. 

4. Inspector 1.0 Access Procedures 

The following are the steps for accessing Inspector 1.0 to review and enter system 

data: 

Step I . Access the web site: http://sysarch.army.mil/EISEInspector. 

Step 2 . Enter system’s user-id, its password, and its domain name. The System 
Administrator (SA) authorizes the password. 

Step 3 . Highlight the desired survey in the choice box, then press the “Select Survey” 
button on the bottom of the page. 

Step 4 . To review & update a system survey, “click” on the “Update” text. 

Step 5 . No special action is required on the “Inspector Search page” simply press the 
“Search” button at the bottom. 
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Step 6 . Use the mouse to “click” on the specific system you are authorized to edit. Use 
the scroll bar on the right to pan down. Once a system has been selected, press the 
“Access Data” button at the bottom of the page. 

Step 7 . The REGISTRATION DATA page for the system should now be showing. The 
frame on the left side of the browser holds a set of buttons used to access various portions 
of the data contained within a survey. Update the registration page and use the “Submit” 
button at the bottom of the page. If the Submit button is not showing, you do not have 
the proper access to edit this system and you need to contact the system administrator to 
report the problem. 

Step 8 . Inspector now presents the top-level questions for the survey selected by the user. 
Answer each question by “clicking” the appropriate iem and/or making text entries. 

After reviewing and modifying as necessary any check-boxes or typed in text, press the 
“Submit Question Data” button at the bottom. A “next” group of questions that are 
driven by the first responses will automatically be presented each time the “submit” 
button is pressed if more questions apply. When the last questions within the survey have 
been answered, a ‘Thank you” page will show on the right frame. The left frame of each 
survey page provides buttons that allow the user to access specific “Categories” of 
question. 

Step 9 . Repeat step 8 for all applicable question sets, one at a time, until the “thank” 
page for each appears. 

Step 10 . Send an email to SA when the data review and update have been completed. 

C. LISI INPUT 

1. LISI Data Collection 

Inspector receives inputs via a system survey questionnaire that forms the bridge 
between the LISI assessment basis and the LISI assessment process and products. LISI 
uses the Interoperability Questionnaire to collect the pertinent information required to 
assess information systems interoperability. Because the questionnaire is linked to the 
LISI models and tables that comprise the assessment basis, the questionnaire covers all of 
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the different implementation choices and characteristics currently defined in the Options 
Tables for the capabilities described within the LISI Capabilities Model. (C4ISR, 1998) 

Users register system characteristics by selecting the appropriate responses to the 
questions. Answers are stored in a table from which data can be used to create a set of 
reports. Questionnaire data is maintained in a “meta-data” format eliminating the need 
for additional software development to extend the data collection range, function, or 
purpose of a questionnaire. According to MITRE in its Inspector version I.O Description 
of August 2000, “New questions can be added at-will whenever the user determines that 
additional detail is needed.” However, at present time, the user will have to submit the 
request for addition to the SA if there is any need. 

2. Information Shared Among Surveys 

Inspector currently provides the ability to utilize multiple questionnaires relating 
to almost any aspect of information technology systems. Inspector provides this 
capability by using a common “front-end” for questionnaire-formatted data that is 
facilitated through a simple, web-based, survey presentation and data collection module. 
Information can then be structured between surveys so that it is directly shared within the 
database. As a result, data being entered into the LISI questionnaire is also automatically 
entered into the other surveys as appropriate. For example, by “marking” the presence of 
Transmission Control Protocol (TCP)/Internet Protocol (IP) in the LISI Survey, it is also 
entered into the DII COE Runtime Compliance Assessment Questionnaire (a COE Level 
- 1 requirement) and is likewise properly registered as a Layer-4 protocol in the OSI 
Reference Model. Similarly, information about a particular USMTF message format 
entered into the LISI survey is also entered into the USMTF Configuration Control Board 
(CCB) Functional Analysis Survey and the Mission Needs Statement (MNS) 
Requirements Profiler. (MITRE, August 2000) 
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3. Expansion of Questionnaires 

There is no limit to the level of detail that ean be entered into a survey 
questionnaire. Inspeetor eurrently eontains approximately 220 questions eovering a wide 
range of topics. These questions now contain over 3,000 possible answers that are 
currently composed of over 12,000 individual response fields. During the Systems of 
Systems Interoperability Evaluation meeting in October 2000, Bruce Thompson, LISI 
Manager from MITRE, indicated that Inspector started with only twenty- five questions in 
the very beginning. When a hard copy was requested in April 2001 to show attributes 
with “all questions,” a stunning 571-page report was printed. 

Although the EISI Interoperability Survey is growing larger on the whole, any 
one system typically answers only a small subset of these questions. The questionnaire is 
organized hierarchically so that only those questions that relate to the capabilities being 
registered for the system need be answered. Eor example, systems indicating Eink-16 on 
a higher- level question would answer an additional eight questions that would not be 
shown to other systems that do not indicate Eink-16 capability. Eikewise, there are 16 
questions about USMTE composed of over 400 different message formats which are 
shown only if “USMTE” is asserted on a higher level question involving what message 
formats are supported within the system. (MITRE, August 2000) 

4. Questions Related to PAID Attributes 

Current questions within the EISI Procedures attribute address the following 
subject areas: 

• What implementation or enterprise directed standards are being followed? 

• What is the system’s security profile; which specific security standards are 
implemented? 

• To what degree has DII COE compliance been attained, if applicable? 

• What information exchange requirement agreements have been attained within 
particular domains, within the DOD Enterprise, across-government agencies, and 
within multi-national forums? 
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Within the Applications attribute, questions are used to evaluate many different 
application selections including such areas as word processing, briefing development 
packages, tabular spreadsheets, imagery display tools, map display tools, and what 
collaboration capabilities exist. 

The two LISI attributes that presently contain the greatest amount of detail are 
Infrastructure and Data. The questions for Infrastructure start by identifying what 
simple interactions exist between systems and progress through radio, networks, and 
types of bands, local area networks, wide area networks, and finally multi-level secure 
configurations. The Data attribute covers the spectrum from proprietary data protocols, 
through advanced heterogeneous data products to full database model implementations. 
(MITRE, August 2000) 

D. LISI PROCESS 

1. Generating an Interoperability Profile 

The system information collected is consolidated and presented by subject area 
and is also mapped to the LISI levels. This information is then kept as the basis for 
constructing interoperability Profiles and performing LISI assessments. The information 
gathered must contain enough detail to allow selection of options that characterize the 
system, based on the implementation choices available in the LISI Options Tables. The 
details are then overlaid on the LISI Capabilities Model to form the system’s 
Interoperability Profile. The LISI Capabilities Model and its supporting LISI Options 
Tables together constitute the “engine” that drives the LISI process and provide the basis 
for developing the LISI products (outputs, will be discussed in Section 3.5). Lor each 
entry identified in the LISI Capabilities Model, there is typically a variety of means and 
implementations possible. The LISI process does not dictate which implementation must 
be used; it captures what has been selected or what is being considered. 

Ligure 3-2 illustrates the process of generating a system’s Interoperability Profile. 
The LISI Capabilities Model is shown on the left. Samples of the associated LISI 
Options Tables for infrastructure implementations are shown in the center of the figure. 
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Figure 3-2 shows the infrastructure portion of the system’s interoperability profile. As 
implied in the figure, for any eapability described in the LISI capabilities Model and 
associated LISI Options Tables, multiple implementations are possible (e.g.. Secret 
Internet Protocol Router Network (SIPRNET), Non-Secure Internet Protocol Network 
(NIPRNET) and Joint Warfare Intelligence Center Systems (JWICS)). Based on the 
answers to the EISI questions for the system under analysis, the system’s characteristics 
are captured and mapped against the options tables. In this example, the system 
represented by SI has SIPRNET and DISN-EES infrastructure capabilities and then 
these characteristics are captured in the system’s interoperability profile. (C4ISR, 1998) 
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Eigure 3-2. Generating an Interoperability Profile, from (C4ISR, 1998) 


2. LISI Levels and Threshold Rules 

A capabilities model provides a means to identify the distinctions among systems. 
It is defined in terms of the discriminators that characterize the specific capabilities 
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within a system. These discriminators determine the specific nature and level of 
interoperability of a system. In order to be assessed at a certain level, systems must fulfill 
all of the requirements identified within the PAID attributes up to the level attained. 
Therefore, the LISI level attained by a system is the “highest line” across PAID up to 
which all of the requisite PAID capabilities have been implemented and whose 
implementations have been assessed as interoperable. Furthermore, for each PAID 
attribute, the level attained within the individual attribute is attained only when all 
capabilities of the lower thresholds are represented within that attribute. 

Decisions about which thresholds within each attribute are essential or can be 
treated as inherited are embodied within two basic rules: 

Threshold Rule 1 : Within the capabilities model, there are explicit and essential 
capabilities that every system must possess. These capabilities act as barriers to being 
rated at a higher level until they are accomplished. For example, if standards compliance 
is defined by the enterprise to be an essential characteristic of the procedures attribute for 
Level Ic/d, then a system that is not standards compliant cannot be rated higher than 
Level lb. This condition applies, regardless of whether all the other characteristics of the 
PAID attributes are otherwise fully Level-2b compliant, including those capabilities 
higher up within the procedures attribute. 

Threshold Rule 2 : Within the capabilities model, thresholds are considered as 
being “credited” to the next higher level if they have not been designated as an essential 
and required capability as defined in Rule 1. For example, if a system possesses the LAN 
characteristic for the infrastructure attribute (Level 2b) and the other three PAID 
attributes also assess at this level, then the system does not specifically require the 
existence or implementation of each lower-level threshold (e.g., removable media) within 
the infrastructure capability to be assessed as Level 2b. (C4ISR, 1998) 

E. LISI OUTPUT 

The collection and process of registered profiles provide the basis for conducting 
system comparisons. The results of these comparisons can be displayed in a number of 
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products that are available to describe single systems and support comparisons between 
multiple systems. These products can be based on any of the user-defined x-y 
coordinate-based reference models included within the tool. LISI Inspector leverages the 
data captured in the questionnaire to generate the following four primary sets of 
assessment products. Each set differs in its presentation, its intended use, and the 
interoperability aspect it considers. (C4ISR, 1998) 

1. Interoperability Profiles 

The Interoperability Profiles map LISI Questionnaire data (answers) to the LISI 
Capabilities Model template. Thus, the profiles capture the implementation choices for 
each PAID capability present in the systems being assessed in a format that facilitates 
system-to-levels and system-to-system comparisons. Individual system metrics can be 
generated from these profiles. 

a. Generic Interoperability Profile 

It maps a single system’s responses to the questionnaire directly to the 
LISI Capabilities Model template. The generic level of interoperability is the highest 
level at which the full suite of capabilities is implemented in a given system across PAID. 

b. Specific Interoperability Profile 

It shows only the common or compatible implementations between the 
two systems , the basis for determining the highest level of sophistication that the two 
systems can support in their interactions with each other. 

c. Composite Interoperability Profile 

It shows the commonalties between a group of systems. 

d. Target Interoperability Profile 

It represents a notional set of system characteristics for use by developers 
when designing new systems or updating existing systems. This profile is different than 
the other three interoperability profiles in that it represents a goal or direction for types 
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or classes of systems . It may initially be constructed from the results obtained using a 
Composite Interoperability Profile for a set of systems from a particular domain. 

e. Variations of Interoperability Profiles 

Variations can be applied to any of the above profiles. The profiles 
described above can be varied in different ways to change the conditions under which the 
information about a system or group of systems is presented. 

2. Interoperability Assessment Matrices 

These matrices interrelate groups of systems based on their generic, expected, and 
specific interoperability metrics, i.e., levels. The results are presented in a “system” 
format that enables each system pair to be compared in depth. The generic level of 
interoperability is the highest level at which the full suite of capabilities is implemented 
in a given system across PAID. The expected level of interoperability is determined by 
comparing the generic levels of any two systems. The specific level of interoperability is 
determined by comparing each system’s specific implementation choices. 

The “scorecard” nature of this product makes it highly useful to all players 
involved in systems development, acquisition, testing, and oversight, as well as to those 
responsible for mission and crisis planning and execution. The following are the three 
types of Interoperability Assessment Matrices: (C4ISR, 1998) 

a. Potential Interoperability Matrix 

It can be generated for a group of systems based on the generic 
interoperability level of each system and the specific interoperability level for each 
system pair within the group. 

b. Evaluated Interoperability Matrix 

This is a form of the Potential Interoperability Matrix that has been 
validated via testing and experimentation. Therefore, this matrix reflects demonstrated 
levels of interoperability attained between systems. It is derived via editing the Potential 

Interoperability Matrix to reflect actual field posture. 
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c. Projected Independence Matrix 

It is developed in the same manner as the Potential Interoperability 
Matrix, except that Projected Interoperability Matrices are provided for phases in time, 
each phase corresponding to a planned or postulated suite of capabilities and 
implementations. 

3. Interoperability Comparison Tables 

These tables present the results of a system to-system PAID implementation 
assessment. They provide a comparison of interoperability implementation information 
between systems in terms of PAID. 

a. PAID Implementation Comparison Tables 

They facilitate attribute-by-attribute examination of the specific PAID 
implementation choices between system pairs, and provide linkages to solution 
alternatives. These tables would be used to determine the Specific Interoperability Level 
between systems as well as to examine the nature of the gaps and solution options 
available. Each table focuses on one of the PAID attributes. 

b. Interconnection Requirements Table 

It represents “data flow” direction between systems. When a PM registers 
a system using LISI, there is a portion of the questionnaire that calls for the identification 
of all other systems involved in the system’s one-way or two-way information exchanges. 
When these identified requirements are compared across systems, unknown or 
unexpected relationships often are exposed. Therefore, the table serves to identify 
conflicts that would require PM-to-PM coordination to resolve. (C4ISR, 1998) 

3.5.4 Interoperability System Interface Description - It reflects the interoperability 
aspects of information technology architectures. LISI currently supports a system 
interface diagram that depicts the interoperability level of individual systems and the 
interfaces between systems that are involved in a particular mission operation or that are 
under scrutiny. 
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F. LISI DATA PRIVACY AND CONTROL POLICY 


LISI data privacy is highly protected by design for all systems registered in LISI. 
However, there is an open security issue, as this writing, regarding the classification level 
the LISI database should properly be set at has not resolved yet. 

There are several control points that would demonstrate this high level of 
protection as depicted in Figure 3-3. 



System 

Maieger 

Owiifid 


Figure 3-3. LISI Privacy & Control Policy, from (Levine, 2000) 


a. The LISI system data is configuration managed by Deputy Chief of Staff for 
Operations (DCSOPS) who has the ownership rights and report access. 

b. The LISI data are input by Program Managers (PM) or System Managers (SM). 

c. The LISI data access is web based and certain software and hardware are required 
for installation and operational use of Inspector as discussed in section 3.2.3. 
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d. Access to LISI System Data Repository is password protected. Each user 
requires a user-ID, password, and domain name. 

e. A System Administrator for each of the Services controls the passwords. 

f The level of data release for export is controlled by the PM or SM who can 
decide his input will either remain as “Private,” be released to “Local,” or be 
reclassified to “Global” when registering the system based on his data completion 
level. (Levine, 2000) 

G. LISI INSPECTOR USER-FRIENDLINESS 

The LISI Inspector, a web-based tool, was designed to provide C4I systems a 
user-friendly process for determining interoperability needs. The questionnaire 
information collected in the Inspector is presented in a user- friendly Hyper Text Markup 
Language (HTML) format, and is captured through an administrative HTML interface. 

The LISI Inspector completed a series of major enhancements during LY 99 to 
make the application of LISI Inspector more user- friendly and meaningful. The 
improvements during LY 99 have occurred through the contributions of several key 
organizations. The contributors include the Air Lorce Electronic Systems Center (ESC) 
C4ISR Interoperability Program Office (CIPO), the Army Systems Electronic 
Engineering Office (ASEO), the Horizontal Technology Integration Office (HTIO) at 
PEO CSS, the Marine Corps Systems Command (MARCORSYSCOM), the Ballistic 
Missile Defense Office (BMDO), the Unified Cryptologic Architecture Office (UCAO), 
and the Joint C4ISR Battle Center (JBC). Each contributor also leveraged the expertise 
of the Program Management Offices (PMOs) and system developers within their purview 
to support the LISI development. The mentioned system developers are referring to 
PATRIOT, Airborne Early Waming/Ground Environment Integration Segment (AEGIS), 
the Theatre Maritime Battle Management Core System (TBMCS), and the Army Battle 
Command and Control System (ABCS). (MITRE, 1999) 

Although the questionnaires currently contain over 220 questions covering 3,000 
possible answers with over 12,000 individual response fields, any one system normally 
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has to answer only a small subset of these questions. The questionnaire is organized 
hierarchically so that only those questions that relate to the capabilities being registered 
for the system need to be answered. Also, because the questionnaire data is maintained 
in a “meta-data” format, new questions can be added “at-will,” whenever the user 
determines that additional detail is needed. (MITRE, August 2000) However, this add¬ 
on capability of “at-will” is indirect at the writing of this study, since the user currently 
can only make a request of any questionnaire change through the system administrator. 

The three- levels of data information release is another user- friendly feature. The 
data input can remain at “Private” level before the system manager or program manager 
reviews and determines that the data input for the system is accurate and complete. The 
users can “Print Survey “ to see the input before re-classifying the information to the next 
level, “Local “ or “Global.” The “Print Survey” also gives the users choices to print the 
“whole survey” or “one attribute” of the four attributes to narrow down and concentrate 
on selected review areas. 

H. CHAPTER SUMMARY 

LISI has been applied through a web-based tool. Inspector 1.0. The Inspector’s 
five major functional components (Survey Questionnaire, Multiple Survey Capability, 
Reports, Questions Builder, and Data Exchange) make it a powerful tool to capture, 
manipulate, analyze, and share data for all of its five system surveys currently available 
(LISI, DIICOE I&RTS v3.I, DIICOE I&RTS v4.0, OSI, and USMTE). Inspector’s 
evolution from a prototype to an operational capability has been driven primarily by 
expansion of the LISI Survey. 

The LISI Survey focuses on the four interoperability attributes: Procedures, 
Applications, Infrastructure, and Data. LISI uses the Interoperability Questionnaire to 
collect the pertinent information required to assess information systems interoperability. 
Users register system characteristics by selecting the appropriate responses to the 
questions and then the answers are stored in a table from which data can be used to create 
a set of reports. 
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The information collected from the LISI Survey is consolidated and presented by 
subject area and is mapped into the LISI levels. The details are overlaid on the LISI 
Capabilities Model to form the system’s Interoperability Profile. The LISI Capabilities 
Model and its supporting LISI Options Tables together constitute the “engine” that drives 
the LISI process and provide the basis for developing the LISI products. However, the 
LISI process does not dictate which implementation must be used; it captures what has 
been selected or what is being considered. 

LISI Inspector leverages the data captured in the questionnaire to generate four 
primary sets of assessment products: Interoperability Profiles, Interoperability 
Assessment Matrices, Interoperability Comparison Tables, and Interoperability System 
Interface Description. Each set of products differs in its presentation, the intended use, 
and interoperability aspect it considers as discussed under section 3.5, LISI Outputs. 

The LISI system data is configuration managed by DCSOPS and its privacy is 
considered highly protected. A user-ID, password, and domain name is required by 
each user each time to access the web-based LISI Inspector. Although the questionnaires 
contain over 220 questions covering 3,000 possible answers with over 12,000 individual 
response fields, any one system normally has to answer only a small subset of these 
questions. Also, new questions can be added through system administrator whenever the 
user determines that additional detail is needed. The data input by the PM or SM may 
remain as a “Private” file, or be reclassified to either “Local” or “Global” depending on 
the level of confidence the PM or SM has on the data provided. 

The LISI Inspector, a web-based tool, was designed to provide C4I systems a 
user-friendly process for determining interoperability needs. It has completed a series of 
major enhancements (contributed by multi-services organizations) during FY99 to make 
the application of LISI Inspector user-friendlier and more meaningful. Also, in October 
2000, Army conducted a Systems of Systems Interoperability Evaluation Meeting to 
embark on a process that will assist the Army in establishing a framework for 
sustainment of an interoperability baseline. The continuing effort in enhancing EISI 
process and implementation to improve C4I system interoperability is anticipated. 
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IV. CAN LISI IMPROVE THE C4I SYSTEMS’ 
INTEROPERABILITY? 

A. INTRODUCTION 

Can LISI improve the C4I systems’ interoperability? The answer is “yes” that 
LISI has the potential to improve DOD C4I systems’ interoperability “but” current LISI 
tool has to be refined. The concept, theory, and mythology discussed in previous 
chapters, the application and use of the LISI process (will discussed in section 4.2), and 
the results from two LISI assessments (will be discussed in the sections 4.3 and 4.4) led 
to the above conclusion. 

The motivation and development of LISI was discussed in detail in Chapters I 
and II. How the LISI process works was also explained in length in Chapter III. LISI 
was initiated in 1993 and developed to comply with requirements that were eventually 
codified in the Information Technology Management Reform Act (ITMRA) of 1996 to 
develop a process and procedure for information technology and to improve system 
interoperability. Some of the motivations of initiating LISI are to help achieve the 
“information superiority” envisioned in Joint Vision 2010, to support Joint Task Force, to 
comply with Information Technology Management Reform Act, and to assist the 
certifying process and improving C4I systems’ interoperability. 

The Army pilot assessment conducted by MITRE Corporation and reported in 
November 1999 indicated that LISI process provides significant added value toward 
Army system Engineering Office (ASEO) and HTIO’s efforts to improve Army Battle 
Command and Control system (ABCS) interoperability. However, the second assessment 
conducted by PEO C3S HTIO Interoperability Group and reported in September 2001 
pointed out that the current tool has many deficiencies and needs to be refined and 
upgraded. 
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B. APPLICATION AND USE OF LISI PROCESS 


This section demonstrates the application and use of the LISI process and the 
potential interoperability improvement capability. It explains how LISI can be used to 
improve interoperability by assessing, identifying, and recommending corrective actions 
for major gaps and shortfalls between and among systems throughout different stages of 
the Army system life cycle. This section also discusses how LISI can be used in different 
phases of Army system life cycle. The collective work performed across all of these 
efforts can significantly enhance the interoperability maturity for Army C4I systems. 

1. To Develop Interoperability Requirements 

LISI can support “requirements” development and analysis for a new program 
through the development of a Target Interoperability Profile (see section 3.5.1.4). 
Current interoperability profiles of existing systems that support a particular function can 
be evaluated using the composite Potential Interoperability Matrix (see section 3.5.2.1). 
This matrix shows the interoperability levels between systems already supporting that 
function. Using this matrix, a Target Interoperability Profile for a given system can then 
be created that will leverage the implementation choices made by other systems that have 
the same functional needs and relationships. The process of generating a Target 
Interoperability Profile for a new system is shown in Figure 4-1 below. 
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Figure 4-1. Establishing Target Interoperability Profiles, from (C4ISR, 1998) 


Step 1 : To retrieve profile information for existing systems that performs a particular 
function. 

Step 2: To build the Potential Interoperability Matrix for the systems that has been 
retrieved. This matrix represents the potential for each system to interoperate with the 
others, and displays the level at which the interactions will potentially take place. This 
matrix shows the interoperability maturity of the systems supporting the selected 
function. Gaps and shortfalls are shown and can be targeted for improvement. 

Step 3 : To combine the profile information for all the systems retrieved into a Composite 
Interoperability Profile. This product will show what all the systems supporting this 
function have in common. This profile can also be added to the previously generated 
Potential Interoperability Matrix to show how such a “composite” system relates to the 
existing systems. Additions and changes can be made to this profile based on improving 
interoperability with existing systems and incorporating future technology directions. 
Varying the capabilities represented in the Composite Interoperability Profile can 
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perform risk analysis and cost/benefit tradeoffs. The impact of these changes can be 
viewed in the Potential Interoperability Matrix and an iterative process used to arrive at 
the desired “composite” result. 

Step 4: To publish the results of the analysis as a Target Interoperability Profile. This 
product provides guidance to PMs and system developers and serves as a benchmark for 
systems that will support this particular function. Thus, as the capabilities of new 
systems are developed to support the function, they are built toward a target that already 
includes interoperability and interfaces to existing systems. On the other hand, where the 
Potential Interoperability Matrix shows gaps or system to-system interoperability issues 
that preclude the clear derivation of “consensus-based” choices, the PMs of the systems 
in question would be engaged collaboratively to reach an agreed-upon strategy for 
resolving the implementation differences. Thus, a two-way benefit is realizable. This set 
of capabilities in the Target Interoperability Profile can be included as a supplemental in 
requirements documents and specifications for the new system. In the DOD, these 
documents include a Mission Needs Statement (MNS) and an Operational Requirement 
Document (ORD). 

A major benefit of using LISI in this manner is that interoperability requirements 
and specifications for the given system would be based heavily on the popular or 
common implementations of the PAID capabilities that are inherent in other systems 
involved in similar Joint information exchanges. This accessible ‘view” into the profiles 
and implementations of other systems underlies a fundamental value of LISI in achieving 
interoperability “convergence’ across DOD over time. 

The following are some representative types of questions that LISI helps to 
answer: 

• What other systems may need to interoperate with System X? 

• What are the specific interoperability characteristics of these systems? 

• Projecting a System-X profile, what does the Potential Interoperability Matrix 
reveal (any gaps or shortfalls)? 

• What strategy will the systems agree to for eliminating interoperability gaps? 
(C4ISR, 1998) 
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2. To Improve Interoperability of An Existing System 

One purpose of the program management proeess is to identify areas for 
improvements in existing systems and to transition to more mature states or higher levels 
of interoperability over time. LISI ean identify interoperability shortfalls of an existing 
system as well as show how ehanges to that system will improve its interoperability. 

After entering the information about a system into LISI, a PM ean then seleet and retrieve 
data about other existing and planned systems for eomparison. This cross-systems 
examination allows PMs to find potential gaps and shortfalls in their own programs as 
well as the impacts to the other programs 

For example, a PM of one system may have made a particular PAID 
implementation choice that impaired the interoperability of that system with two other 
systems. By using LISI, the PM can identify the potential problem and rectify the 
condition in the analysis phase of development rather than discovering the issue after 
fielding. 
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Figure 4-2. LISI Use by PM of an Existing System, from (C4ISR, 1998) 
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How LISI can be used by the PM of an existing system to improve 
interoperability is depicted in Figure 4-2 above. 

Step 1 : To enter data about the system. This data goes into a central LISI repository 
where other system PMs will have access to it for doing comparisons. 

Step 2 : To retrieve LISI data about other relevant systems. The PM performs this task 
by selecting the appropriate systems from the database. 

Step 3 : To construct a Potential Interoperability Matrix based on profiles for selected 
systems. 

Step 4: To compare the systems and to detect potential interoperability gaps and 
shortfalls that appear between the systems. 

For each potential problem between two systems, the PM can examine the 
implementations to determine if the problem can be remedied by changing an 
implementation selection. The PM can then change LISI data to perform a what-if 
analysis. The PM can then examine the risk and cost-effectiveness of making the 
changes required. 

Some of the questions that LISI can help to answer are: 

• What is the specific LISI potential level of interoperability of System X? 

• What specific interoperability issues exist between System X and other systems 
already in place or planned? 

• What is required to raise System X to a higher level of interoperability? (C4ISR, 
1998) 


3. Use of LISI as an Interoperability Tool for Command Architects 

The command architect can retrieve LISI data for systems that comprise an 
existing or planned architecture. After using LISI to perform an assessment of those 
systems, the architect can build LISI overlays to architecture products, e.g., the Systems 
Interface Description (LISI Overlay, see section 3.5.4). The architect can then evaluate 
alternative strategies to improve interoperability to meet the mission and operational 
requirements of concern. Figure 4-3 below illustrates the process: 
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Figure 4-3. LISI Use by a Command Architect, from (C4ISR, 1998) 


Stepl : The command architect determines which systems are used in the architecture 
under analysis. 

Step 2: The architect retrieves LISI information for those systems from the LISI 
database and then builds a Potential Interoperability Matrix to evaluate the systems. 

Step 3 : The command architect builds a System Interface Description (LISI Overlay) 
corresponding to the operational architecture view under evaluation. Figure 4-3 clearly 
depicts the interoperability levels of each relevant system and the connecting interfaces in 
context with the operational requirement, if known. Using notations and colors, this 
diagram highlights shortfalls where the achievable interoperability is not sufficient to 
support the mission needs. Where mission needs are not clearly defined, the diagram 
depicts discrepancies between the systems’ assessed generic, expected, and specific 
levels of interoperability (see section 3.5.2 for definitions). 
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Step 4: The command architect can use LISI to identify interoperability shortfalls 
graphically. The command architect can evaluate alternatives by modifying the 
information on the systems involved and re-running the analysis. 

Given a new system to integrate into an existing architecture, LISI can help the 
command architect answer the following types of questions: 

• What is the assessed LISI level for the new system? 

• Which systems within the existing architecture is this system potentially capable 
of interoperating immediately? 

• If known, with which system(s) does this system need to interoperate? (C4ISR, 
1998) 

4. Use of LISI for Interoperability “On the Fly” 

LISI can be used to assess interoperability of existing systems, as they are being 
planned and combined for operational use. For example, the DOD Joint Task Forces 
(JTF) does not exist until the need arises. When a crisis appears imminent, a variety of 
systems are brought together by the Services and Agenc ies who will be participating in 
the mission. These systems may or may not interoperate; the new crisis could dictate 
system-to-system relationships that have not been conceived of before. When the JTF 
has a short lead time, the problems associated with getting disparate systems to 
interoperate may force the Commander of the JTF to get by without critical information 
that otherwise would be accessible and transferable if the supporting systems interoperate 
at the requisite levels. LISI can be used at any point the JTF crisis “life cycle” to help 
identify and mitigate interoperability problems. This application may be repeated 
throughout the life cycle of the JTF many times as systems and nodes come and go within 
the architecture. Figure 4-4 below depicts the process: 
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Figure 4-4. LISI Use to Assess Interoperability “On the Fly”, from (C4ISR, 1998) 


Step 1 : JTF planner determines which systems will support the JTF. Then, the JTF 
planner retrieves LISI data for those systems from the LISI data repository. 

Step 2: The planner builds the Potential Interoperability Matrix for all of the systems to 
evaluate the potential of each of the systems to interoperate. 

Step 3: The JTF planner builds a JTF System Interface Description (LISI Overlay) based 
on JTF operational requirements and system relationships. The foundation of the 
diagram shows the mission’s node-to-node information need lines and required 
interoperability levels. The diagram then “overlays” the supporting systems and assesses 
where the LISI level of interoperability is not sufficient to satisfy the need line 
requirements. 

Step 4 : The JTF planner can evaluate alternatives by modifying the interoperability 
profiles of the systems involved and re-running the analysis. When an acceptable 
alternative is reached, the systems can be modified, if practical, to change their interface 
characteristics as required such as adding an Ethernet card to a machine to allow it access 
to an Ethernet EAN. Rapid analysis and improvements can be facilitated by EISFs 
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process and augmented by an appropriate test environment, such as Joint Battle Center 
and federated laboratories. 

Given the need to make disparate systems interoperate in a short time, LISI can 
help a JTF planner determine the following: 

• Does the right kind of interconnection exist between systems? 

• What are the “critical” pathways? 

• What capabilities need to be deployed to augment the infrastructure that is in 
place? 

• Can the necessary data get to the right person in the time required? 

• What vulnerabilities exist with respect to interoperability? 

• What additional applications are needed to support the required collaborative 
exchanges? (C4ISR, 1998) 

5. To Support Assessment and Certification 

LISI can also be used to support the assessment and certification of systems and 
applications. One way this can be accomplished is by using LISI data submitted with 
requirements documents, such as Mission Needs Statement (MNS) and Operational 
Requirement Document (ORD) for a new program in the preparation of the Test and 
Evaluation Master Plan (TEMP). The approved TEMP would include EISI assessment 
criteria that evaluate a system’s interoperability level. The results of these 
interoperability evaluations can be documented in the test reports. Eor example, the test 
report could show that System X is certified at an overall interoperability level of 2a and 
could also report the individual P, A, I, and D levels (i.e.. Procedures = 2a, Applications 
= 2b, Infrastructure = 2c, and Data = 2c). Eigure 4-5 depicts this process. 
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Figure 4-5. LISI Use to Support Systems Assessment and Certifieation, from 

(C4ISR, 1998) 


Step 1 : LISI data for the system to be eertified is retrieved from the LISI database. 

Step 2: A Potential Interoperability Matrix is built based on the interoperability 
profiles of the existing and planned systems. 

Step 3: Testing is eondueted to ensure that all systems demonstrate the 
interoperability levels specified in their profiles. 

Step 4: The results are then included with the systems’ certification documentation. 
(C4ISR, 1998) 

The use of LISI to support systems/application assessment and certifications is most 
noteworthy. Generally, newly developed DOD systems are to be denied production 
approval if they have not been certified. After a system has been fielded and a 
modification is made that affects interoperability, the system must be re-certified. A 
GAO report of March 1998, “Weaknesses in DOD’s Process for Certifying C4I Systems’ 
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Interoperability,” identified several weaknesses in the eertifying proeess (see seetion 
2.3.4 for more information). LISI was one of the initiatives mentioned in the report that 
would improve ways of eomplying with the eertifieation proeess and would lead to 
resolution of many of the issues related to interoperability. 

C. YES, LISI HAS POTENTIAL TO IMPROVE ARMY SYSTEM 
INTEROPERABILITY 

In support of the ASEO and in eoordination with the HTIO, MITRE Corporation 
eondueted the Army pilot assessment and reported in November 1999 that EISI ean 
improve ABCS interoperability. This assessment was eondueted by applying the EISI 
prototype to various interoperability aspeets of the Army Battle Command System 
(ABCS) only. The report indieated, “The findings of this assessment elearly indieate 
how the EISI proeess provides signifieant added value towards ASEO/HTIO’s efforts to 
improve ABCS interoperability. The eolleeted ABCS systems data suffieiently 
demonstrated the EISI methodology and Prototype eapabilities that are now available for 
exploitation by ASEO/HTIO.” (MITRE, November 1999) 

1. Background of the LISI Pilot Assessment 

In November 1999, Army System Engineering Offiee (ASEO), PEO CSS 
Horizontal Teehnology Integration Offiee (HTIO), and MITRE Corporation eompleted a 
joint effort in assessing EISI using eomponents of the Army Battle Command System 
(ABCS). The assessment effort was eondueted between 1 Mareh and 30 September 1999 
and the final report was eompleted in November 1999. 

The report diseusses the development and use of the EISI prototype tool in its 
applieation to Army Systems, mainly, the eleven highly eomplex ABCS systems. The 
eleven systems inelude Advaneed Eield Artillery Taetieal Data System (AEATDS), Air 
and Missile Defense Planning and Control System (AMDPCS), All Souree Analysis 
System (ASAS), Combat Serviee Support Control System (CSSCS), Digital Topographie 
Support System (DTSS), Eoree XXI Battle Command _ Brigade and Below (PBCB2), 
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Global Command and Control System - Army (GCCS-A), Integrated Meteorological 
System (IMETS), Integrated System Control (ISYSCON), Maneuver Control System 
(MCS), and Tactical Airspace Integration System (TAIS). 

The report of the pilot assessment recognized that its data might not be complete, 
detailed or fully validated: “Since the current ABCS data in LISI has not yet been 
validated, the LISI analysis conducted during this assessment was limited to providing 
initial observation, not definite conclusions, regarding ABCS interoperability.” 

(MITRE, 1999) Although the interoperability profiles and matrices produced from the 
assessment might not reflect the true interoperability postures among the eleven systems 
at the time during the pilot assessment, the information available on these systems was 
sufficient to demonstrate the LISI methodology and prototype capabilities that are now 
available. (MITRE, 1999) 

2. Data Analysis from the Pilot Assessment 

The LISI Prototype’s analytical capability was exercised with the set of collected 
data. LISI Prototype reports were examined with respect to (I) their inherent value in 
assessing information systems interoperability, and (2) specific observations for ABCS 
component interoperability. Using System I as an example, the following paragraphs 
demonstrate how the System I data is analyzed, mapped to matrix and profile, and used 
for identifying shortfalls and recommending remedies. 

a. Generic Interoperability Profile 

It maps System Ls (a single system’s) responses to the questionnaire 
directly to the LISI Capabilities Model. This mapping forms the basis for determining a 
system’s generic interoperability level. The generic interoperability level is the highest 
level of sophistication at which a system could generally be expected to interact with any 
other system in an environment or community. The generic level is calculated by 
examining the system profile from the bottom up and determining the highest level at 
which implementations are present across the four attributes, P, A, I, and D. Ligure 4-6 
shows how the generic interoperability profile for System I is summarized as “Ic.” 
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Generic Interoperability Profile 
System I ABCS 6.0 

The metric for System I is: Ic (Pic A4a I3c D2c) 
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Figure 4-6. Example Generic Profile for System I, from (MITRE, 1999) 

b. Generic Interoperability Levels (Reported Level) 

They are summarized in Eigure 4-7 below. Waiving JTA compliance 
would produce the indicated “Waived’ level. The System I generic interoperability level 
of “Ic” was derived from the generic interoperability profile as shown in Eigure 4-6 
above. 


65 
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Figure 4-7. Generic LISI Levels Based on Reported Capabilities, from (MITRE, 1999) 
c. Interoperability Assessment Matrix 

It was derived from some of eight complete sets of ABCS system surveys 
and as shown in Figure 4-8 below. The boxes are colored and indicated in the legend. 

To prevent the indifference of the colors when it is printed in black and white, the boxes 
are also indicate the color by a capital letter corresponding to its appropriate legend, that 
is, B for Black, G for Green, L for Blue, R for Red, and Y for Yellow as shown below. 
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Figure 4-8. ABCS 8-System Interoperability Assessment Matrix, from (MITRE, 1999) 

This matrix indicates major gaps or significant shortfalls (red conditions) 
for 5 system pairs. System I-to-System F and System G-to-System F do not currently 
reflect a requirement to interact. The remaining 3 pairs (System A-to-System G; System 
Tto-System A; and System I-to-System D) have interaction limitations identified in their 
respective individual interoperability profiles. 

d. Specific Interoperability Profiles 

It is used to examine a particular interoperability assessment matrix cell in 
greater detail to find gaps and shortfalls, and to indicate solutions. Attributes 
{Procedures, Applications, Infrastructure, and Data) are each detailed to identify specific 
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common and different capabilities. Specific Interoperability Profiles were generated for 
one of the ABCS system pairs: one of the “red” conditions (System I-to-System D). 
They are assessed as examples of how the LISI profile may help identify and resolve 
problems. Figure 4-9 identifies the interoperability levels of each attribute for the 
following system pairs. 


System Pair 

Combined 

PAID 

Procedures 

Applications 

Infrastructure 

Data 

System I-to- 

System D 

Od 

Ic 

3a 

Od 

2b 


Figure 4-9. LISI Interoperability Levels for the System Pairs, from (MITRE, 1999) 

3. Findings from the Pilot Assessment 

In its final report of the pilot assessment, MITRE Corporation concluded that 
application of the EISI Prototype demonstrates EISTs potential utility in making useful 
insights in improving interoperability of Army systems. Eor ASEO and HTIO, EISI 
presented profiles of the current ABCS components at a level of detail sufficient to: 

• Discern the level of sophistication at which the ABCS components could 
potentially interact. 

• Define the nature of that interaction. 

• Characterize the capability improvements in each program, such as adding 
mapping or office automation to the applications, adding infrastructure 
capabilities, or adopting of domain data models. 

• Provide a perspective for requirement-based interoperability assessments, such as 
providing AEATDS Interface Control Document (ICD) view versus AEATDS 
PMO view. 

The findings of this assessment clearly indicate that the EISI process provides 
significant added value towards ASEO and HTIO’s efforts to improve ABCS 
interoperability (MITRE, 1999). 
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D. BUT, THE CURRENT LISI TOOL HAS TO BE REEINED AND 
UPGRADED 

PEO CSS HTIO was tasked by Directorate of Integration (DOI) to provide 
suggestions for improvements to the LISI questionnaire and associated reports. In 
September 2001, HTIO submitted a LISI Linal Report and Analysis to DOI. The primary 
source of the data for this evaluation covers DOTselected ABCS systems. (Paterson, 
2000) The PEO CSS HTIO also manages this data collection. In the report, HTIO 
indicated that there are deficiencies in the LISI tool, particularly in the on-line 
questionnaire, and refinement and upgrade of LISI tool is needed. The following 
discussions include some examples of the findings and recommendations from HTIO 
assessment. 

1. Expand the Question and Answer Choices 

• Under (Attributes/Procedures) the question entitled Operating Environment 
Types, there are more environments than the choices would indicate, need to have 
an add-in box to accommodate. 

• Under question Document Exchange Lormats, we need an expanded dropdown 
list box. 

• Under question Operation Networks, answer choices provided are not adequate or 
comprehensive enough. Lor example, there is no Tactical Internet Upper or 
Tactical Internet Lower operational network as the Army uses. Additionally, 
these questions must have fill- in boxes because explanations are critical to explain 
particular system hardware set-ups within their infrastructure. (Stubins, 2001) 

2. Clear Ambiguous and Misleading Questions 

• There is quite a bit of confusion concerning the exact definition of the differences 
between the JVML messages and the (old) VML messages. Exactly what it meant 
by when asking if a user uses (old) VML messages. 
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• Under Removable Media, what are we looking for, the device itself? Or the 
media in the device? 

• Under question Security Measures, this question needs to be tightened up 
considerably. There are numerous categories security measures fall under. This 
is another case of the question meaning anything the user wants it to mean. 

• Throughout the questionnaire users are asked whether or not items are available 
and if they are required. The question of what is and isn’t required falls outside 
the goals of the LISI questionnaire. Questioning the users requirements only 
serves to feed the users insecurities about hidden agendas. (Stubins, 2001) 

3. Require knowledgeable Person to Input LISI Data 

Garbage in and garbage out, the LISI output for the interoperability assessment 
and improvement are only as good as the data. LISI tool uses the Interoperability 
Questionnaire to collect the pertinent information through the web-based Inspector 
version I.O. The questionnaire is linked to the LISI models and tables that comprise the 
assessment basis. 

Inspector currently contains approximately 220 questions composed of over 
12,000 individual response choices. Each field checked for every question eventually 
will lead to a profile decision-making. The person inputting the data needs to be 
thoroughly knowledgeable about the C4I system itself, to know how to use the LISI tool, 
and to properly fill out each of the questionnaire for useful analysis. 

4. Concentrate on Fewer Reports with the Highest Quality 

In the second assessment report, HTIO indicated LISI test outcomes depend on 
algorithms that are unknowns to the world outside the coder. It is difficult if not 
impossible to intelligently comment on “black boxed” report outcomes without 
possessing knowledge of the processes that are driving the report outcomes. HTIO also 
recommended that the entire LISI report structure requiring replacement with a modem, 
customer-centric design. A requirements description detailing the necessary reports 
needs to be written. (Stubins, 2001) 
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E. PROVIDE EUNDING AND RESOURCES TO UPGRADE LISI 


HTIO, PEO CSS has been the Army lead in LISI efforts. After the pilot 
assessment, HTIO reeognized the need for LISI eontinuing improvement and submitted a 
Rough Order of Magnitude (ROM) estimate on 21 October 1999 to request for funding in 
the amount of over $800,000. (PEO CSS, 1999) The estimate was to fund maipower 
and training for Database Logical Design and Physical Schema, System/Server 
Architecture and Interface Design, Application Design and Development, Database 
Initialization, and Training. In addition, the funds are needed to purchase three servers 
with workstations for System Development Environment, Web application development 
tools, SQL Server Development Environment, MS Developers Kit, VB Development 
Environment, ERWin, and NetVis or VISIO for output graphics, etc. However, the 
funding was never approved. 

To correct the deficiencies as discussed above will cost money, therefore, funding 
and resources should be property allocated. Also, “Interoperability is an ideal condition 
that can be approached but never totally achieved because of the dynamic nature of 
military operations, system acquisition, and technology improvements.” (JITC, 2001) 
Therefore, the continuing of LISI evolution and maintenance is unavoidable and the 
funding to continue the enhancement and maintenance of LISI is essentially required. 

E. CHAPTER SUMMARY 

After the data about the existing and developing systems have been registered 
using the LISI Interoperability Questionnaire and are stored in a repository or database 
for easy access, LISI can provide a quantitative interoperability assessment for Program 
Managers (PMs) and system developers to assess their program interoperability during 
the entire system life cycles. LISI can be used in developing interoperability requirement 
for a new system. It can improve interoperability of an existing system/application. It 
can be used as an interoperability tool for command architects. It can be used for 
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interoperability “on the fly.” Also, it can be used to support interoperability assessment 
and certification. 

MITRE Corporation concluded in its 1999 assessment for HTIO that application 
of the LISI Prototype demonstrated LISI’s potential utility in making useful insights into 
C4I Systems for improving interoperability of Army systems. It also clearly indicated 
that the LISI process provides significant added value towards ASEO and HTIO’s efforts 
to improve ABCS interoperability (MITRE, 1999). 

However, in the 2001 assessment, HTIO indicated that the current LISI tool 
needed to be refined. The choices of questions and answers need to be expanded. 
Ambiguous questions have to be cleared or avoided. LISI data has to be input by persons 
knowledgeable in both the C4I systems and LISI tool. Reports produced should only be 
high quality and meaningful. To correct the above deficiencies will cost money and 
should be funded. Also, the resources should be provided to upgrade, to operate, to 
maintain, and to continue the evolution and enhancement of the LISI system. 

To answer the prime thesis question, as whether LISI can improve the C4I 
systems’ interoperability, the answer is that LISI has potential to improve DOD C4I 
systems’ interoperability, but the current LISI tool has to be refined and upgraded. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY 

The military services have a long history of interoperability problems during joint 
operations. The success of the Persian Gulf War in 1991 was hampered by a lack of 
basic interoperability. Since then, the DOD has had a number of initiatives to address 
various aspects of interoperability, such as Joint Tactical Architecture (JTA), Defense 
Information Infrastructure (DII)/Common Operating Environment (COE), DII Master 
Plan, Shared Data Environment (SHADE), Joint Battle Center (JBC), and Joint 
Interoperability Test Command (JITC). Among these initiatives, EISI is the key tying all 
the initiatives together. 

Commencing in 1993, MITRE Corporation has been the developer for EISI 
process and its associated software applications and EISI has continued to advance in 
capability through several evolutions: The Exploratory Phase in 1994, Analysis Phase in 
1996, Proof of Concept Phase in 1997, Development Phase and pilot assessment in 1999, 
culminated in the mandatory use of EISI in 2000. The 1999 Development Phase was 
accelerated as the result of the GAO report entitled: Joint Military Operations: 
Weaknesses in DOD’s Process for Certifying C4I Systems’ Interoperability.” A pilot 
assessment of EISI using components of ABCS was conducted by MITRE Corporation in 
1999. The mandate of EISI use was directed on 15 August 2000. And the final report of 
the second assessment by HTIO was submitted on 28 September 2001. 

My personal interest in the area of information system interoperability started in 
August 1997 when I worked in the HTIO, PEO CSS, which manats fifty-plus mission 
critical CSS systems and has been designated as the Army lead in the EISI efforts. I 
continue to have the firsthand information on EISI progress even after moving to PM 
TRCS, one of PEO CSS PM offices, in October 2000. My associate thesis advisor, Mr. 
Tony Kunsaitis, is the Interoperability Manager for PEO CSS. Mr. Kunsaitis has 
introduced me to the wonder world of the information system interoperability and the 
progress of EISI development. 
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Although LISI was initiated in 1993, it is still foreign to the majority of the 
program management eommunity even today. I had originally planned for my thesis to 
show how the LISI ean help PMs and hoped to eonvinee them to use LISI. When the use 
of LISI beeame mandatory in August 2000,1 ehanged my thesis eoneentration on 
whether LISI ean improve C4I systems interoperability. 

In order to examine how LISI ean improve DOD C4I systems’ interoperability, 
detailed explanation of the LISI system itself was diseussed in both Chapters II and III. 
Chapter II provided the overview of LISI, its definition, elements, and assoeiated proeess. 
It also introdueed the motivations for LISI initiation and implementation. Chapter III 
illustrated how LISI is applied, its seeurity, and its user friendliness. Muehof the 
baekground information was refereneed from the C4ISR Arehiteetures Working Group’s 
LISI report of 30 Mareh 1998. 

Chapter IV answered the prime researeh question as to whether LISI ean improve 
C4I interoperability. The eoneept, theory, mythology, the applieation and use of the LISI 
proeess, and the results from the two LISI assessments led to the eonelusion of this thesis. 
The eonelusions made in this thesis that LISI ean improve the information system 
interoperability are based on the researeh available as of this writing and is summarized 
in the following seetion. 

B. CONCLUSIONS TO RESEARCH QUESTIONS 

1. What Is LISI? 

LISI is a formal Referenee Model, an assessment implementation of the 
interoperability maturity model, and a struetured proeess for improving interoperability 
between varied information system. The LISI tool provides an automated, web-based 
interoperability assessment eapability. The heart of the LISI eoneept is the formulation 
of a system ’’profile,” whieh was ereated by LISI web-based tool, Inspeetor 1.0. The 
“profile” may beeome the eommon denominator for determining interoperability between 
C4 systems but it eertainly not a preseription for guaranteeing interoperability. 
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Therefore, LISI is a tool and process to assess and measure but not to guarantee the 
interoperability of information systems. 

2. What Are Central Elements of LISI And Associate Process? 

The LISI process focused on defining and assessing systems against increasing 
levels of sophistication for system-to-system interaction. The process defines thresholds 
of capabilities that a system exhibits as it improves and matures in its ability to interact 
with other systems. These thresholds become levels of interoperability that can be 
measured consistently throughout the system’s life cycle. LISI also categorized the 
various aspects of information systems interoperability in terms of four comprehensive 
and closely interrelated attributes. Therefore, the “Levels” and the “Attributes” are the 
essential elements of LISI. LISI considers five increasing levels of sophistication with 
respect to exchanging and sharing information and services. Each higher level represents 
a demonstrable increase in capabilities over the previous level of system to-system 
interaction. This increase is expressed in terms of the PAID attributes - the Procedures 
imposed by information management, the capabilities of Applications that act on that 
data, the type of Infrastructure required, and the nature of Data transferred. 

3. What Are the Motivations to Implement LISI? 

• To Achieve Information Superiority: LISI was initiated in 1993 after the 
difficulties of basic interoperability experienced during the Persian Gulf War in 
1991. The Information Superiority envisioned by the Chairman of the Joint 
Chiefs of Staff in his Joint Vision 2010 in 1997 further challenged the 
development and implementation of LISI. 

• To Support Joint Task Force: Although the DOD Joint Task Lorces does not 
exist until the need arises, it is crucial to have existed quick access and ready 
information whenever the need arises to bring together the supporting systems, 
which need to be interoperate at the requisite levels. LISI can be used at any 
point the JTL crisis “life cycle” to help identify and mitigate interoperability 
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problems. This application may be repeated throughout the life cycle of the JTF 
many times as systems and nodes come and go within the architecture. 

• To Comply with Information Technology Management Reform Act: The 
ITMRA of 1996 requires the Federal Government to develop “a process and 
procedure for establishing goals for improving the efficiency and effectiveness of 
government agencies” operations and the ability to deliver goods and services to 
the public using information technology. The goals must be measurable.” Prior 
to LISI, there were no widely accepted performance-based and results-based 
standards for interoperability. Now LISI directly supports the development of IT 
architectures within the context of ITMRA by assessing the level of 
interoperability required and attained between systems. 

• To Assist in Certifying Process and Improving C4I Systems” 
Interoperability: GAO identified several weaknesses in DOD’s process for 
certifying C4I systems” interoperability in its March 1998 report and 
recommended that a number of interoperability improvement initiatives had to be 
continued. LISI was one of the initiatives recommended in the report. GAO also 
indicated “DOD’s 1993 LISI initiative is to improve C4 and intelligence systems’ 
interoperability. System developers are to use this tool to assess interoperability, 
to determine capabilities needed to support system development, and to determine 
the degree of interoperability needed between C4I and other systems.” 

• To Become a Mandatory Interoperability Evaluation Tool: The Director of 
Information System for C4 and the Military Deputy to the Assistant Secretary of 
the Army (AL&T) mandated on their joint memorandum of 19 August 2000 that 
the HQDA to employ LISI framework and its associated interoperability 
assessment tool to address SoS interoperability. The rationale was that the 
technical data stored in LISI along with LISI output products satisfy the C4ISP 
requirements for a technical architecture profile and view. 
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4. How Does LISI Process Work? 

LISI uses the LISI Survey through a web-based tool, Inspectorl.O to collect the 
pertinent information required to assess information systems interoperability. User 
register system characteristics by selecting the appropriate responses to the questions and 
then the answers are stored in a table from which data are used to create a set of reports. 

The information collected from the LISI Survey is consolidated and presented by 
subject area and is mapped into five LISI levels (zero through four) and in terms of four 
LISI attributes (P, A, I, and D). The detailed information is overlaid on the LISI 
Capabilities Model to form the system’s Interoperability Profile. The LISI Capabilities 
Model and its supporting LISI Options Tables together constitute the “engine’ that drives 
the LISI process and provide the basis for developing the LISI products. 

LISI Inspector leverages the data captured in the questionnaire to generate four 
primary sets of assessment products: Interoperability Profiles, Interoperability 
Assessment Matrices, Interoperability Comparison Tables, and Interoperability System 
Interface Description. Each set of products differs in its presentation, the intended use, 
and interoperability aspect it considers. 

5. Is the LISI System Secure? 

LISI data privacy is considered highly protected for all systems registered in LISI. 
There are several control points that would demonstrate this high level of protection: 

• Deputy Chief of Staff for Operations who manage the system configuration and 
has the ownership rights and report access. 

• Program Managers, Systems Managers or their delegates input the data. 

• The LISI data access is web based and certain software and hardware are 
required. 

• Access to LISI System Data Repository is password protected. Each user requires 
a user-ID, password, and domain name. 

• A System Administrator for each of the Services controls the passwords. 

• Each Program Manager or Systems Manager can decide the level of information 
release by registering the system as “Private,” “Eocal,” or “Global.” 
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6. Is the LISI System User Friendly? 

The LISI Inspector, a web-based tool, was designed to provide a C4I-wide user- 
friendly process for determining interoperability needs. The questionnaire information 
collected in the Inspector is presented in a user-friendly Hyper Text Markup Language 
(HTML) format, and is captured through an administrative HTML interface. 

The LISI Inspector completed a series of major enhancements during FY 99 to 
make the application of LISI Inspector more user-friendly and meaningful. Although the 
questionnaires currently contain over 220 questions covering 3,000 possible answers with 
over 12,000 individual response fields, any one system normally has to answer only a 
small subset of these questions. The questionnaire is organized hierarchically so that 
only those questions that relate to the capabilities being registered for the system need to 
be answered. 

The three-levels of data information release is another user-friendly feature. The 
data input can remain at “Private” level before the system manager or program manager 
reviews and determines that the data input for the system is accurate and complete. Also, 
the users can “Print Survey” to review the input before re-classifying the information to 
the next level or choose to print the “whole survey’ or “one attribute” at a time. 

7. Can LISI Improve DOD C4I Systems’ Interoperability? 

The answer is a “yes, but ...” Yes, LISI has potential to improve Army systems 
interoperability but current LISI tool need to be refined and upgraded. 

LISI was initiated in 1993 and designed and evolved to comply with the 
Information Technology Management Reform Act of 1996 to develop a process and 
procedure for information technology and to improve system interoperability. A 
prototype assessment of the LISI using components of the ABCS was used to 
demonstrate how LISI could be used to improve interoperability. MITRE in its final 
report of the pilot assessment clearly indicated that the LISI process provides significant 
added value towards ASEO and HTIO’s efforts to improve ABCS interoperability. 

HTIO reported in September 2001 from the second assessment that the EISI tool 
has many deficiencies and need to be refined and upgraded. The choices of questions and 
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answers need to be expanded. Ambiguous questions have to be cleared or avoided. LISI 
data has to be input by persons who are knowledgeable in both the C4I system and the 
LISI tool. Reports produced should only be high quality and meaningful. Also, the 
resources should be provided to upgrade, to maintain, and to continue the evolution and 
enhancement of the LISI system. 

C. RECOMMENDATIONS FOR FURTHER STUDY 

The further study may include but not limited to the following areas: 

• LISI Management Support : The mandate of LISI in August 2000 appeared rot to 
have gotten the attention of all levels of management. As of today, LISI is still 
foreign to most of the program management community. Further study may 
explore the reasons for this drawback and provide recommendation for 
improvement. 

• LISI Funding Resources : As discussed in section 4.4.5, the continuing of LISI 
evolution and maintenance is unavoidable and the funding to continue the LISI 
enhancement and refinement is essentially required. Further study may discuss 
where the continuing funding should be resourced. 

• LISI Tool Advertising : LISI is using the Inspector 1.0, a web-based tool, to 
capture, manipulate, analyze, and report interoperability assessment. The tool is 
effective, rather secure, and user-friendly although it requires further refinement 
and upgrade. However, the tool is still foreign to the majority of the program 
management community as of today regardless the fact that LISI was initiated in 
1993. In order to expand the user population more advertising and training efforts 
are required. Therefore, how to sell the tool might be an area for further study. 

• LISI Data Accuracy Assurance : Garbage in and garbage out, the LISI output for 
the interoperability assessment and improvement are only as good as the data. In 
addition to having the knowledgeable person input the data, the possible 
mechanisms to coordinate and trigger the updates of database will be an added 
value to the LISI system and should be explored. 
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• LISI Continuing Evolution and Enhancement : LISI has come a long way to 
today’s pilot assessments. It has evolved since its inception in 1993. Each 
evolution refines and enhances the LISI system and should be continued. Further 
study should be continued to assess the current LISI system and application and to 
recommend ways for improvement. 

• Validation of LISI Usefulness Based on GAO Recommendations : GAO 
identified several weaknesses in DOD’s process for certifying C4I systems’ 
interoperability in its March 1998 report. It also endorsed LISI initiative in the 
report and recommended that system developers use LISI for assessing 
interoperability, determining capabilities needed, and determining the degree of 
interoperability needed between C4I and other systems. After the LISI 
implementation becomes C4I system wide, a further study should be conducted to 
show if and how LISI can improve the deficiencies identified in the GAO report. 

In its final report of the Pilot Assessment of LISI Using Components of the 
ABCS, ASEO and HTIO anticipated that a “joint’ interoperability assessment would be 
feasible in early FYOO. As of this writing, the anticipation was overly optimistic, 
therefore, the findings from the Pilot Assessment of ABCS, which are only part of the 
C4I systems, were used to derive the conclusions. Further study should be conducted as 
soon as the “joint” interoperability assessment is made possible and all the C4I systems 
are included in the database. 

Interoperability is an ideal condition that can be approached but never totally 
achieved because of the dynamic nature of military operations, system acquisition, and 
technology improvements. Therefore, the continuing of LISI evolution and 
enhancements is unavoidable. It is my sincere desire that the above-recommended areas 
be further studied, ways to enhance LISI system can be implemented, improvements on 
C4I system interoperability can be realized on a continuing basis, and collectively, we 
can achieve the information Superiority envision by Joint Vision 2010. 
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APPENDIX A - ACRONYMS AND ABBREVIATIONS 


A&T 

ABCS 

AEGIS 

AFTDS 

AIMIS 

AMC 

AMDWS 

ASAS 

ASD 

ASEO 

AWG 

BCC 

BMDO 

CCB 

CDG 

CECOM 

CIPO 

COE 

csscs 

C2 

C3I 

C3S 

C4I 

C4ISP 

C4ISR 


DA 

DAMO 

DCSOPS 

DII 

DISA 

DOD 

DOI 

DTSS 

ESC 

FBCB2 

FDD 


Acquisition and Technology 

Army Battle Command and Control Systems 

Airborne Early Waming/Ground Environment Integration Segment 

Advanced field Artillery Tactical Data System 

Army Interoperability Management Information System 

Army Materiel Command 

Air and Missile Defense Workstation 

All Source Analysis System 

Assistant Secretary of Defense 

Army System Engineering Office 

Architectures Working Group 

Biological Chemical Command 
Ballistic Missile Defense Olfice 

Configuration Control Board 
Competitive Development Group 
Communications and Electronics Command 
C4ISR Interoperability Program Office 
Common Operating Environment 
Combat Service Support Control System 
Command and Control 

Command, Control, Communications, and Intelligence 
Command, Control, and Communications Systems 
Command, Control, Communications, Computers, and Intelligence 
C4I Support Plan 

C4I Surveillance and Reconnaissance 


Department of Army 

DA Military Office (Office of Deputy Chief of Staff for Operations) 

Deputy Chief of staff for Operations 

Defense Information Infrastructure 

Defense Information Systems Agency 

Department of Defense 

Directorate of Integration 

Digital Topographic Support System 

Electronic Systems Center 

Eorce XXI Battle Command - Brigade and Below 
Eirst Digital Division 
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GAO 

General Accounting Office 

GCSS-A 

Global Combat Support System - Army 

HQDA 

Headquarters, Department of the Army 

HTIO 

Horizontal Technology Integration Office 

HTML 

Hyper Text Markup Language 

lAP 

Integrated Architectures Panel 

I&RTS 

Integration and Runtime Standards 

ICD 

Interface Control Document 

IF 

Intelligence Fusion 

IMETS 

Integrated Meteorological System 

IOC 

Initial Operational Capability 

IP 

Internet Protocol 

ISC 

Intelligence Systems Council 

ISO 

International Standard Organization 

ISYSCON 

Integrated Systems Control 

IT 

Information Technology 

Internet Protocol 

ITF 

Integration Task Force 

ITMRA 

Information Technology Management Reform Act 

JBC 

Joint Battle Center 

JCPAT 

Joint C4 Program Assessment Tools 

JITC 

Joint Interoperability Test Command 

JS 

Joint Staff 

JTA 

Joint Technical Architecture 

JTF 

Joint Task Force 

JULLS 

Joint Universal Lessons Learned Systems 

JWICS 

Joint Warfare Intelligence Center 

LISI 

Levels of Information Systems Interoperability 

MCS 

Maneuver Control System 

MARCORSYSCOM 


Marine Corps Systems Command 

MNS 

Mission Needs Statement 

NIPRNET 

Non-Secure Internet Protocol Network 

ORD 

Operational Requirements Document 

OSD 

Office of the Secretary of Defense 

OSI 

Open Systems Interconnection 
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PAID 

PEO 

PM 

PMO 

Procedures, Applications, Infrastructure, and Data 
Program Executive Office 

Program Manager 

Program management Office 

QDR 

Quadrennial Defense Review 

RMA 

ROM 

Revolution in Military Affairs 

Rough Order of Magnitude 

SA 

SHADE 

SIPRNET 

SM 

SoS 

STAMIS 

System Administrator 

Shared Data Environment 

Secure Internet Protocol Network 

System Manager 

System- Of- S ystems 

Standard Army Management Information System 

TACOM 

TAIS 

TBMCS 

TCP 

TEMP 

TM 

Tank Automotive Command 

Tactical Airspace Integration System 

Theatre Maritime Battle Management Core System 
Transmission Control Protocol 

Test and Evaluation Master Plan 

Theater Missile 

UCAO 

USD 

USMTF 

Unified Cryptology Architecture Office 

Under Secretary of Defense 

US Message Text Eormat 

VCJCS 

Vice Chairman of the Joint Chiefs of Staff 
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